У меня есть база данных с более чем 10 000 000 строк. Запрос прямо сейчас может занять несколько секунд, чтобы найти основную информацию. Это не предпочтительнее, я знаю, что лучший способ оптимизации – минимизировать количество строк, которое возможно, но сейчас у меня нет времени для этого.
Какой самый простой способ оптимизировать базу данных MySQL, чтобы при запросе было короткое время?
Я не возражаю против размера базы данных, это не имеет большого значения, поэтому любые оптимизации, которые увеличивают размер, прекрасны. Я не очень хорошо разбираюсь в оптимизации, прямо сейчас у меня установлены индексы, но я не уверен, насколько лучше я смогу туда добраться.
Я, в конечном счете, правильно отрегулирую базу данных, но есть ли быстрое временное решение?
Помимо индексации, которая уже была предложена, вы можете также посмотреть в таблицы разбиения, если они большие.
Разбиение в MySQL
Трудно быть конкретным здесь, потому что у нас очень ограниченная информация, но правильная индексация вместе с разделением может пройти очень долго. Правильная индексация может быть длинной темой, но в очень общем смысле вам нужно индексировать столбцы, к которым вы обращаетесь.
Например, скажем, у вас есть таблица сотрудников, и у вас есть обычные столбцы SSN, FNAME, LNAME. В дополнение к этим столбцам мы скажем, что у вас есть еще 10 столбцов в таблице.
Теперь у вас есть этот запрос:
SELECT FNAME, LNAME FROM EMPLOYEES WHERE SSN = 'blah'; Игнорируя тот факт, что SSN, вероятно, может быть основным ключом здесь и может иметь уникальный индекс, вы, вероятно, увидите преимущество в производительности, создав еще один составной индекс, содержащий столбцы (SSN, FNAME, LNAME). Причина, по которой это выгодно, заключается в том, что база данных может удовлетворить этот запрос, просто глядя на составной индекс, поскольку он содержит все значения, необходимые в отсортированном и компактном пространстве. (т. е. меньше ввода-вывода). Несмотря на то, что индекс SSN является лучшим методом доступа к выполнению полного сканирования таблицы, база данных все еще должна считывать блоки данных для индекса (ввода-вывода), находить значения (-ы), которые будут содержать указатели на записи необходимых для удовлетворения запроса, тогда вам нужно будет прочитать разные блоки данных (прочитайте: более случайный ввод-вывод), чтобы получить фактические значения для fname и lname.
Это, очевидно, очень упрощено, но использование индексов таким образом может значительно сократить объемы ввода-вывода и повысить производительность вашей базы данных.
Некоторые другие ссылки здесь могут оказаться полезными:
Поскольку я вижу, что вы запрашиваете 40k строк из базы данных, для этой загрузки данных требуется время для передачи.
Кроме того, никогда не спрашивайте «как улучшить вообще». Нет никакой «общей» оптимизации. Оптимизация всегда является результатом профилирования и исследования вашего конкретного случая.
Используйте индексы по столбцам, которые вы часто просматриваете.
В вашем примере «WHERE x = y», если y является именем столбца, также создайте индекс с y.
Ключ с индексом – это № результата из вашего запроса select, который должен составлять около 3% ~ 5%, сравнивая всю таблицу, и он будет быстрее.
Также помогает архивирование таблицы. Я не знаю, как это сделать, в основном задача DBA. Для DBA это простая задача, если они это делают.
Если вы выполняете заказы или сложные запросы, вам может понадобиться использовать индексы с несколькими столбцами. Например, если вы ищете, где x.name = 'y' OR x.phone = 'z', возможно, стоит поместить индекс по имени, телефону. Упрощенный пример, но если вам нужно это сделать, вам все равно нужно исследовать его дальше 🙂
Ваши запросы используют ваши индексы? Что говорит вам об EXPLAIN в ваших избранных запросах?
Первый (и самый простой) шаг будет гарантировать, что ваши запросы будут оптимизированы.