Часто для обслуживания сайта требуется использование рутинных скриптов, которые используются лишь время от времени, а потому забываются, но каждый раз писать их где-то, потом находить сложно.
Если бы заготовки хранились прямо на сайте, это было бы удобно.

Предлагаю в Битрикс виртуальную машину пред устанавливать по умолчанию не стандартный MySQL, который обладает хроническими болезнями бекапирования, кластеризации и т.д., а Percona Server for MySQL в данной сборке большая часть проблем стандартного MySQL уже решена. Данное решение повысит производительность отказоустойчивость и производительность решений на базе Битрикс.

Добрый день.

Хотелось бы "из коробки" получить возможность составлять SQL запросы для полей типа JSON в MySQL 5.7
По аналогии с https://habrahabr.ru/post/278935/

1)
На странице (Рабочий стол/ Контент / Highload-блоки) перечислены  MySQL таблицы.

При  добавлении новой таблицы не задействовано системное поле “Комментарии к таблице”, это поле очень сильно помогает разобраться (особенно  когда количество таблиц весьма большое) зачем была создана та или иная таблица.

Прошу использовать  системное поле “Комментарии к таблице”


2)

Визуально группировать Highload-блоки по их  названиям (вернее по  префиксам таблиц)

например есть перечень таблиц:
- list_workers
- other_table1
- list_person
- other_table3
- list_report
- list_blablabla
- other_table2
....
- other_tableN

Такие таблицы  в админке хорошо бы  сгруппировать  в выпадающие  списки
“list_” ->LIST  и
“other_” ->OTHER  
так  же как это  представлено  при добавлении нового типа инфоблоков,  тогда получим :

[+] LIST:
[-]  list_workers    / комментарий к таблице (кол-во строк)
[-]  list_person     / комментарий к таблице (кол-во строк)
[-]  list_report / комментарий к таблице (кол-во строк)
[-]  list_blablabla       / комментарий к таблице (кол-во строк)
[+] OTHER  
[-] other_table1  / комментарий к таблице (кол-во строк)
[-] other_table3  / комментарий к таблице (кол-во строк)
[-] other_table2  / комментарий к таблице (кол-во строк)
[-] other_tableN / комментарий к таблице       (кол-во строк)


думаю такое визуальное представление   Highload-блоков  более наглядно для сопровождающего,  удобнее читать и ориентироваться всем)

Иногда бывает удобно загружать файлы напрямую в базу с использованием одного запроса.
Было бы удобно, если бы можно было создать соединение с использованием указанной опции.

Возможность фильтрации через or по всем полям во всех инфоблоках

Например, CSaleLocation -> cFilter->where('REGION_NAME'=>'Москва')->or('CITY_NAME'=>'Москва'). Суть не в форме здесь.

Возможность использовать mysql функции в aRfilter, сортировка по любым полям любых типов данных (локации, заказы и т.д.)
Возможность группировки по любым полям. Надоело спотыкаться и изобретать велосипеды.

https://dev.1c-bitrix.ru/api_help/main/reference/cdatabase/insert.php
Исходя из этой документации через DB->Insert()  можно заводить за 1 раз только одну строку, было бы удобно делать единовременно множественную вставку нескольких строк, чтобы ускорить процесс

В попапе расширенного редактирования свойств http://joxi.ru/Xk-UUtg5CbAzQrMim_g
Нужно добавить такие параметры как тип значения притом именно MySql тип с описанием его, так же не нужно создавать столбец с описанием значения, если галка "Выводить поле для описания значения:" не установлена.


Во первых эти не значительные изменения избавят нас от части проблем которые возникают у людей имеющих большое количество свойств, примеры по ссылке:
https://dev.1c-bitrix.ru/search/?q=Row+size+too+large.&x=0&y=0

А во вторых сами файлы таблиц будут меньше, индексы компактее, запросы будут работать шустрее и т.д.

Сейчас каждый просмотр элемента инфоблоков, вызывает UPDATE таблицы iblock_element. Вынос статистики просмотров в отдельную таблицу позволит значительно повысить эффективность работы mysql за счёт кеша запросов.
Это стоит сделать не только для инфоблоков, но и рекламы(просмотры баннеров) и форумов(просмотры тем) блогов(просмотры записи) и т.п.

Интересно, есть в планах? mysql-расширение уже объявлено как deprecated

Имеется некая база данных. Имеется следующий код:


$arSel ect2 = Array("ID", "NAME", "PROPERTY_USER", "PROPERTY_ZAKAZ", "PROPERTY_CAT_ID", "PROPERTY_CAT_ARTICUL", "PROPERTY_CAT_MANUF", "PROPERTY_CAT_NAME", "PROPERTY_CAT_SUPPLIER", "PROPERTY_CAT_DATE", "PROPERTY_CAT_PRICE", "PROPERTY_CAT_QUANT";);
$arFilter2 = Array("IBLOCK_ID"=>$IBLOCK, "ACTIVE_DATE"=>"Y", "ACTIVE"=>"Y", "PROPERTY_USER"=>$_REQUEST["uid"], "!PROPERTY_ZAKAZ"=>5, "SECTION_ID"=>$_REQUEST["sid"]);
$res2 = CIBlockElement::GetList(Array(), $arFilter2, false, Array(), $arSelect2);
while($ob2 = $res2->GetNextElement()) {
 $arFields2 = $ob2->GetFields();    
}


На данный момент вот в данном инфоблоке, находится всего два элемента. Вообще в базе, около 4000 элементов, с разными свойствами. Сервер - отдельный физический сервер. Centos6. Веб окружение Битрикс с оптимальными конфигурационными файлами.

Время выполнения кода выше - 33 секунды.

Проблема:

SELECT COUNT('x') as C
FR OM
b_iblock B
INNER JOIN b_lang L ON B.LID=L.LID
INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
INNER JOIN b_iblock_property FP0 ON FP0.IBLOCK_ID = B.ID AND FP0.CODE='USER'
LEFT JOIN b_iblock_property FP1 ON FP1.IBLOCK_ID = B.ID AND FP1.CODE='ZAKAZ'
LEFT JOIN b_iblock_property FP2 ON FP2.IBLOCK_ID = B.ID AND FP2.CODE='CAT_ID'
LEFT JOIN b_iblock_property FP3 ON FP3.IBLOCK_ID = B.ID AND FP3.CODE='CAT_ARTICUL'
LEFT JOIN b_iblock_property FP4 ON FP4.IBLOCK_ID = B.ID AND FP4.CODE='CAT_MANUF'
LEFT JOIN b_iblock_property FP5 ON FP5.IBLOCK_ID = B.ID AND FP5.CODE='CAT_NAME'
LEFT JOIN b_iblock_property FP6 ON FP6.IBLOCK_ID = B.ID AND FP6.CODE='CAT_SUPPLIER'
LEFT JOIN b_iblock_property FP7 ON FP7.IBLOCK_ID = B.ID AND FP7.CODE='CAT_DATE'
LEFT JOIN b_iblock_property FP8 ON FP8.IBLOCK_ID = B.ID AND FP8.CODE='CAT_PRICE'
LEFT JOIN b_iblock_property FP9 ON FP9.IBLOCK_ID = B.ID AND FP9.CODE='CAT_QUANT'
INNER JOIN b_iblock_element_property FPV0 ON FPV0.IBLOCK_PROPERTY_ID = FP0.ID AND FPV0.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV1 ON FPV1.IBLOCK_PROPERTY_ID = FP1.ID AND FPV1.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV2 ON FPV2.IBLOCK_PROPERTY_ID = FP2.ID AND FPV2.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV3 ON FPV3.IBLOCK_PROPERTY_ID = FP3.ID AND FPV3.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV4 ON FPV4.IBLOCK_PROPERTY_ID = FP4.ID AND FPV4.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV5 ON FPV5.IBLOCK_PROPERTY_ID = FP5.ID AND FPV5.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV6 ON FPV6.IBLOCK_PROPERTY_ID = FP6.ID AND FPV6.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV7 ON FPV7.IBLOCK_PROPERTY_ID = FP7.ID AND FPV7.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV8 ON FPV8.IBLOCK_PROPERTY_ID = FP8.ID AND FPV8.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_element_property FPV9 ON FPV9.IBLOCK_PROPERTY_ID = FP9.ID AND FPV9.IBLOCK_ELEMENT_ID = BE.ID
LEFT JOIN b_iblock_property_enum FPEN0 ON FPEN0.PROPERTY_ID = FPV1.IBLOCK_PROPERTY_ID AND FPV1.VALUE_ENUM = FPEN0.ID
INNER JOIN ( SELECT DISTINCT BSE.IBLOCK_ELEMENT_ID
FR OM
b_iblock_section_element BSE
INNER JOIN b_iblock_section BS ON BSE.IBLOCK_SECTION_ID = BS.ID
WHERE
((BS.ID IN (3700))) ) BES ON BES.IBLOCK_ELEMENT_ID = BE.ID
WH ERE
1=1 AND ( ((((BE.IBLOCK_ID = '12')))) AND (((BE.ACTIVE_TO >= now() OR BE.ACTIVE_TO IS NULL) AND (BE.ACTIVE_FROM <= now() OR BE.ACTIVE_FROM IS NULL))) AND ((((BE.ACTIVE='Y')))) AND ((((FPV0.VALUE LIKE '1')))) AND ((( FPV1.VALUE_ENUM IS NULL OR NOT (FPV1.VALUE_ENUM = '5')))) ) AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)))    


Этот запрос занимает всё время. И результат его работы - просто подсчет количества элементов...

ЗАЧЕМ????

Мне НЕ нужно в данном случае считать элементы! ПОЧЕМУ нельзя или обойтись без этого запроса совсем, или сделать некую переменную через которую управлять подсчетом??? Передана функции переменная - посчитали. Нет - ничего не считаем.

Проблема имеет общий характер.

Обобщая это звучит так:

Если вы используете функцию CIBlockElement::GetList, вам нужно сделать выборку из инфоблока с большим количеством свойств, и нужно выбрать эти свойства, производительность падает фатально. И чем больше размер у вас бд, тем хуже и фатальней результат.

Столкнулся с такой проблемой: при резевном копировании дамп базы хранится в одном файле, но во время разворачивании бэкапа на хостинге, mysql упирается в лимит количества запросов (лимит на хостинге 3 000 000 запросов, записей в базе больше 7 000 000, самая жирная таблица 3 700 000). Было бы весьма к месту иметь возможность дробить дамп базы на файлы по количеству запросов, либо обновить restore.php для исключения падения процесса восстановления при превышении лимита запросов

Сейчас в веб окружении используются «консервативные» версии софта.
MySQL 5.0.51,
PHP 5.2.6,
eAccelerator 0.9.5.  
Apache 2.2.8,

Оно используется для тестов.
Почему бы не включать в него последние стабильные версии?

У БУС есть возможность при работе системы обновления запрашивать версию PHP и MySQLЯ считаю, что статистику по использованию версий ПО на активных лицензиях показывать надо для разработчиков маркетплейса. Например - в карточке партнёра.

Так мы будем видеть, что имеет уже смысл вести разработку с учётом новых версий ПО.