> Но не скажется ли это на работе в других местах...
Если скажется - Вы это сразу заметите когда что-то перестанет работать. Если есть прямой доступ к серверу по SSH / SFTP, то зачем держать FTP сервер, занимающий память, и собирающий сканеры портов словно мух?
EXPLAIN EXTENDED SELECT * FROM table1 WHERE key1=value1 AND key2=value2 AND id>97262353; EXPLAIN EXTENDED SELECT * FROM table1 WHERE key1=value1 AND key2=value2 AND date>1590969600;
При условии по primary key (id) type=range, по дате ref.
possible_keys в 1 случае PRIMARY, key2, key1; во втором - date, key2, key1 (видимо, обратный порядок это норма).
Длина ключа 8 ref=NULL, если по дате длина 4 ref = const. Сильно сокращает время "Using index condition".
Что с длиной ключа я не понимаю, key1 - tinyint (1 байт), key2, id и date - int (4 байта). Как из этого получаются цифры 4 и 8 не ясно, используются только 2 индекса, на остальные база кладёт? Чуть раньше пробовал принудительно USE INDEX на key1, key2, date либо просто key1, key2 - разницы по времени не заметил.
Mobiaaa, UNIX_TIMESTAMP()-864000 и php time()-864000, подставленное в запрос, не дает существенной разницы по времени выполнения запроса (засекаю время только mysqli_query, fetch не произвожу). Не заметил. Предполагаю что MySQL считает цифру один раз до прохода по таблице.
LEOnidUKG, это тест! Оптимизация базы и подбор носителя для ее хранения. Реальные запросы, даже самые тяжелые, на старом железе занимают до 5 секунд, а я хочу доли секунды. Я сейчас намеренно гоняю базу по всей таблице, в результате чего у меня по 44 секунды на запрос идет. Если при каком-то действии 44 секунды вдруг уменьшатся до 30 это эффективная оптимизация, если бы это было 4.4 против 3.0 я бы разницу не заметил и списал разницу на любой другой фактор (крон задача в этот момент обращалась к памяти или что-то еще). В одном из реальных запросов используется COUNT после выбора по критериям, и подсчитываются только несколько тысяч записей. Пусть подсчитываются, без этого нельзя и это не занимает много ресурсов если все остальное работает быстро.
Осилил приближенное вычисление значения id (primary key) по date (timestamp) с точностью достаточной для выполнения необходимой задачи. Выигрыш WHERE id>xxx (id unsigned int(4) - primary) перед WHERE date>yyy (date unsigned int(4), индекс ) на MyISAM в 3.5 раза, Ariadb 3.25 раз, InnoDB в 7.4 раза. Это уже успех, но останавливаваться на этом пока еще не готов. Всё равно пока еще не понял, почему primary работает быстрее обычного индекса.
> это не полноценный поиск
Пардон, фигню сморозил. Да, полнотекстовый использовал в какой-то задаче но не здесь.
> Вообще никакой и никогда
А об этом можно подробнее? При сравнении 2 запросов
SELECT * FROM table1 WHERE [key1]=[value1] AND [key2]=[value2] AND date>[xxx]SELECT * FROM table1 WHERE [key1]=[value1] AND [key2]=[value2] AND date>[xxx] AND myvarchar LIKE '%blablabla%'
получаю во втором существенно меньшее число строк, удовлетворяющих условиям, но время, затраченное на сам запрос, одинаково для всех механизмов хранения. Например, MyIsam 22.22 и 21.46 сек, InnoDB 82.41 и 79.16 сек.
В памяти держать не вариант, памяти не больше 2 GB. Уже писал.
По поводу id1 + id2 не понял, Вы имеете в виду сделать так чтобы в WHERE стояла выборка только по индексам? Вторая колонка это timestamp, миллионы разных значений, а не десяток как по другим индексам кроме primary (id). Кто-то когда-то говорил что делать индекс по таким данным нельзя, нецелесообразно или что-то в этом духе. Добавил индекс, +200 мегабайт к размеру таблицы (что составляет где-то по +11.5 байт на каждую строчку, индексируемая колонка - 4-байтный integer). 10 тестовых выборок не ускорились, начинаю думать как такое возможно - и оказывается, что я время уже сделал индексом в прошлый раз, но забыл об этом. Все тесты делались уже по индексам.
> SELECT SQL_NO_CACHE count(*) FROM table1 WHERE key1=value1 AND date>UNIX_TIMESTAMP()-864000;
44 секунды, почти лям записей
> SELECT SQL_NO_CACHE count(*) FROM table1 WHERE key1=value1 AND date=1594119617;
0.01 сек, 48 записей
1.26 сек, 1.7 млн записей.
(все 3 теста на InnoDB). Получается, что условие WHERE primary_key > some_value работает на порядок быстрее чем WHERE index > some_value? Видимо, буду писать функцию преобразования id (primary) <> date (приближенную, табличную, хз какую раз это быстрее), заменять дату на первичный индекс во всех запросах, и убирать индекс по date для экономии дискового пространства.
Отредактировать пост почему-то не могу. Баг был какой-то, таблица с char вместо varchar занимала место на диске, но все выборки из нее выдали 0 записей, пришлось очистить и скопировать ее заново.
Выводы о преимуществах Char перед Varchar неверные. Varchar дает 70 секунд, char 80 секунд и при этом занимает существенно больше места на винте.
Между Varchar(512) и Varchar(255) существенной разницы по времени выполнения нет. По занятому дисковому пространству ровно за счет укорачивания некоторых длинных записей (которых мало) отличия 5%.
Или так... Продолжаю эксперименты. Взял в цикле на php 10 тестовых выборок SELECT * FROM ... WHERE ... квазиодновременно (1я из каждой таблицы, потом 2я и так далее). Т.е. одинаковые запросы, отличающиеся только значением по ключу, соответственно разное число строк в выборке. Считаю суммарное время. Запрос включает полнотекстовый поиск (LIKE '%___%').
MyISAM дало 20.99 сек, Aria 20.52, InnoDB 75.33 секунд все на NVMe.
Дальше сделал копию InnoDB таблицы где одно из полей (varchar 512) сменил на Char 255 (больше не принималось, видимо однобайтная длина строки). Тест дал 0.04 секунды при тех же 20.70 на Aria.
Без полнотекстового поиска (в условии WHERE один индекс и один целочисленный не индекс) Aria 18 сек, InnoDB 71.9, InnoDB Char 0.04 сек. Полнотекстовый поиск тут не при чём, основное время занимает обход таблицы с полями переменной длины. При том что судя по докам, в основной таблице хранится только адрес, а значение поля переменной длины хранится где-то в Тмутаракани, или я что-то путаю?
Все, я понял, Cipher Suites обрезали. ssllabs.com сразу показывает что с ними лажа. Наборы шифров сервера одни ECDSA, где привычные TLS_ECDHE_RSA? Надо хотя бы TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 добавить.
Нет, нет, не роскомголубые. Пинг есть, с Лисы все нормально, прокси / VPN / турбо не использую.
Все сайты открываются, Серч - нет. Когда "что-то с сертификатами" - пишет ERR_SSL_VERSION_OR_CIPHER_MISMATCH, либо INADEQUATE_TRANSPORT_SECURITY, это если наборы шифров совпадающие на клиенте и сервере отсутствуют (есть кривые сервера с сильно урезанным набором поддерживаемых шифров, в результате часть десктопов и половина мобильных зайти на сайт не могут)
Тут вообще пишут что если без WHERE то MyISAM берет count из метаданных, Inno считает.
А если с WHERE то в обоих движках идет проход по данным и не должно быть существенных различий во времени. Но они есть. На порядок.
