Помогите оптимизировать запрос MySQL

Просто индекс id лишний, как я уже писал быстрее PK ничего нет, в вашем запросе используется индекс (столбец key), если бы не использовался там был бы NULL.

Запрос то не выполняется...

Запрос или explain? Сколько выполняется запрос на 100 id?

Милованов Ю.С, делить смысла нету, так как полная база нужна для общих запросов.

В общей таблице ищем общие запросы.

Вот результат:

source FULL

{

        type            = mysql

        sql_host        = localhost

        sql_user        = root

        sql_pass        = 12345

        sql_db          = ZP

        sql_port        = 3306

        # Для ускорения работы прописываем путь до MySQL-го UNIX-сокета (чтобы 

        # операции с БД происходили не через TCP/IP стек сервера)

       sql_sock        = /var/run/mysqld/mysqld.sock

    

        

        sql_query_pre = SET NAMES utf8

        sql_query_pre = SET CHARACTER SET utf8



		        sql_query		= \

		SELECT * \

		FROM FULL

}

Sphinx то отрабатывает нормально, это уже потом MySQL запрос долго выбирает данные по ID.

Возможно, хотел поделить список ID по 1000 и делать N запросов по 1000 ID, но решил всётаки тему создать и спросить почему всётаки такая медленная выборка по большому списку ID. Может в конфиге my.cnf что-то подкрутить?

Кстати может можно как-то в Sphinx сделать чтобы он выводил вместо ID нужное мне поле и тогда не надо было бы делать дополнительный запрос в таблицу MySQL?

Нет, записи сфинкс не хранит, только индексы.

1. Какой размер таблицы? В мегабайтах?

2. Замерьте время выполнения select * from table

3. Какими ресурсами сервера вы располагаете?

---------- Добавлено 04.02.2013 в 18:22 ----------

Для повышения производительности на высоконагруженных проектах частенько делают сознательную денормализацию (избыточное хранение) данных. Ничего вы этом такого страшного нет.

Кстати, еще один вопрос, а что происходит с этими 30 тысячами записей дальше? Вы их все вываливаете пользователю одновременно? Или все же, с постраничным делением?

1) 95,2Гб

2) Отображает строки 0 - 29 (1,151,918,377 всего, запрос занял 0.0005 сек.)

3) Core I5-760, 10ГБ ОЗУ

Записываются в текстовый файл.

Можно попробовать:

- postgresql (перенести)

- percona

- увеличить память на сервере и дать большее количество под кеш БД

- попробовать в цикле брать малыми частями данные из БД

- использовать систему кеширования, выловив часто используемые данные.

но тут везде надо вникать в систему, её задачи, архитектуру

Думаю, есть смысл затестить... Есть ощущение, что сервер лишнее пытается на диск записать (кэшировать? другие приложения из памяти в SWAP скидать). А что "на графиках" в момент запроса?

p.s. Если в кэш складывает - можно SELECT SQL_NO_CACHE попробовать - результат ведь повторно не скоро потребуется?

настройки мускуля так же покажите.

Есть вариант переехать на SSD, чтобы туда повесить базу и пусть там будет чисто она одна.

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

По поводу популярных чуть выше:

уверен дело не в миллиарде, а как раз в этих 30к, сам запрос получается большой по длине (в смысле текст) и всё время в основном уходит на его разбор и преобразование громадного параметра IN ().

Рекомендую вам либо разбить запрос на составляющие, например по ~1к, тем более, что выборка идёт по id значит рез. значения и так будут без повторений

или второй вариант передать параметр id в in не явным образом, а например через запись в промежуточную таблицу, а затем уже её через обычный join соединить с вашей FULL, а ещё лучше ☝ переписать запрос в обратную сторону в виде

SELECT (SELECT b.`mazda-323` FROM `avtozapchasti` b WHERE b.`id` = a.`id`) as `mazda-323` from `tmptable` a

но тут желательно проверить:) хотя я более чем уверен.

Попробуйте и отпишите какой выигрыш🤪

p.s.

и кстати для массовой выгрузки и загрузки рекомендую использовать SELECT ... INTO OUTFILE и LOAD DATA INFILE будет в разы быстрее, чем по 1 записи ковырять

Да вы попробуйте список значений поменьше. Если план изменится - надо делать серию запросов. Или просто выражение force index. Ведь у вас там индексы в possible_keys перечислены, то есть в принципе могли бы быть использованы, но оптимизатор выбрал полное сканирование.

И кстати, есть интересные варианты скрещивания sphinx и mysql - отдельный storage engine для mysql, который фактически позволяет в одном sql-запросе объединять данные из sphinx и mysql. Но это больше для удобства.