В памяти держать не вариант, памяти не больше 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 то в обоих движках идет проход по данным и не должно быть существенных различий во времени. Но они есть. На порядок.
Если бы у меня было 32 ГБ памяти на халяву - так бы и сделал. К сожалению, идея не катит.
Бенчмарк гонялся в режиме случайного доступа, а не последовательного. Он создает сколько-то файлов равного размера, суммарно заданного размера, потом происходит в них рандомное чтение, рандомная запись, или чтение-запись (как оно конкретно работает - не вникал). В моем понимании именно так работает MySQL: по ключам определяются смещения нужных записей в Талмуде, дальше идет setfilepointer() и ReadFile() либо WriteFile() (прошу прощения за терминологию Windows API, другой не знаю, и вообще тут Linux) и считываются блоки данных по нужным смещениям из многогигабайтного файла.
> COUNT(*) убивают любую InnoDB
COUNT(*) это обычный счетчик, инфа сама не передается за счет этого по идее экономия ресурсов. На реальных запросах там счет идет максимум на пару тысяч записей, удовлетворяющих запросу. Все всегда отрабатывает в пределах 5 сек, но хочу быстрее. Сейчас я специально гоняю MySQL по всей таблице (95% попало по критерию) чтобы найти наиболее быстрый способ хранения данных (без учета того что повторные запросы быстрее отрабатывают за счет кеширования, причем не базы, а кеширования дисковых операций). С MyISAM я уже определился - если запрос касается выборки только по индексу, и не проверяет другие колонки, можно файл индекса кинуть на NVM / SSD, а файл с данными - на HDD, при больших объемах данных существенная экономия денег выйдет, время выполнения запроса - то же как будто все лежит на SSD. Если же в запросе проверяется какой-то не индекс то что-то среднее получается по времени между чисто HDD и чисто SSD. Но в InnoDB и данные, и индексы лежат в одной братской могиле, её не распилишь. А если у тебя будет скрипт 2 минуты дописывать туда новые данные и блокировать MyISAM таблицу, в это время в очереди висеть запросы, ожидающие UNLOCK, при этом половина из них отваливаться либо по таймауту (автоматические) либо обрубаться CloudFlare по причине бекенд не ответил, это не подходит.
> почему не может упираться в него сильнее, чем в диск?
Если база на NVMe - камень загружается на 96%, Iotop на MySQL показывает 10%. Получается что вот он потолок всего. Но когда на SSD камень загружен только на 70% для InnoDB или 30% на MyISAM / Aria - тут узкое место диск. Правильно понимаю? Чтение с HDD показывало 21% CPU на Isam / Aria и до 64% на Inno, iotop 79 и 42% соответственно.
> ну так ведь оно и есть в большинстве случаев когда диск, не предназначенный для этого заставляют много записывать
Раньше не встречал. Всегда хостинг на SSD и хостинг на HDD существенно отличался, а тут мало того что скорость, так я еще баранам объясняю что у них раз в 10 минут кто-то на 3 секунды полностью кладет сеть своими кронами (рост пинга на все IP из интервала, включая мой), а они отвечают что специалисты работают над этим вопросом и ответят когда разберутся. И так уже пол года. Переезд уже без вариантов. Сейчас просто пытаюсь сообразить как грамотнее запустить эту базу, но пока самому сообразить не получается.
Google Cloud тоже не разрешает подключения к 25 порту, причем ни при каких обстоятельствах, договориться и порешать вопросы нельзя :)
Пользуюсь IHC около 6-7 лет, ПО сервера не переустанавливал, не помню чтобы хоть раз обращался в ТП. С Namecheap не знаком.
Отличная вещь! К таким джойстикам еще обычно плата шла в комплекте на 2 порта (2 джойстика) и не помню каким разъемом.
Видел такой джойстик год назад приделанный под управление станком. Внутри - джойстика оригинальная плата, но варварским методом удалены все детали, в нескольких местах перепилены дорожки, установлены 4 кнопки, откушена "лишняя" кнопка в ручке, это всё присобачено к RS-232 разъему которым вкручено в корпус. Кустарщина, но двигать устройство по 2 осям и активировать то что там перемещается - можно, джойстик вполне справляется с поставленной задачей 😂
