Новая тема   Ответить

 ibiz
собсно при работе с 10м записей в таблице SELECT ... LIMIT 1 запрос подтормаживает на 2-3 сек... с 10к записями все норма
вопрос, как можно оптимизировать операции с таблицами больших объемов?

 janso
Одназначно мало информации для ответа.

http://dev.mysql.com/tech-resources/presentations/presentation-oscon2000-20000719/ конечно же читал уже?

 leroy_17
ты бы структуру таблицы показал бы ?

 ibiz
Код:

 Stek
индексы добавь сначала.
А потом все зависит от железа, типа запроса.

 xreload
1) везде varchar() замени на char().
2) если база в 10м записей, убери KEY `user_id` (`user_id`).
3) сконвертируй базу в InnoDB тип.

Чудес на обещаю, но должно помочь.

 nostalgie
Ставишь форум на такую железку и всё будет нормально работать

Цитата:

Это форум. Там при каждом открытии страницы куча запросов с выборкой по этому полю проходит.

А вообще, надо сам запрос увидеть. Вслепую тока ёжики сношаются

 Corex
Как вариант - разделить таблицу на 3-4 или более, где в каждой будет 1-2 млн. записей, выборку делать по user_id > N/M/K и т.д. Т.е., если (user_id > 0 && user_id <= 1500000) table = phpbb_users_1, если (user_id > 1500000 && user_id <= 3000000) table = phpbb_users_2 и т.д. Это довольно распространённая практика при делении нагрузки, выхлоп очень неплохой. Такой свитчер ставиться до запроса к базе в приложении (в скрипте PHP, например). Если в PhpBB все SQL-запросы идут через 1 интерфейс (класс вроде adodb), то можно подобный свитчер воткнуть прямо в функции запроса - это 4-5 строчек кода.

При этом, конечно, индексов бы ещё воткнуть и хорошо бы отключить функционал форума, который делает не особо нужные update/delete (вроде last visit time, last ip и т.п.), т.к. это лочит таблицу при каждом запросе.

 xreload
nostalgie писал:

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

 nostalgie
xreload
Я знаю о чем говорю. Я предположил, что выборка идет по user_id. Если убрать с этого поля индекс - тормоза намного увеличатся.

А вообще, топикстартер чего-то недоговорил. Если это чистый phpbb - то приведена неправильная структура таблицы. Если phpbb интегрирован в другой движок, почему нет слов о тормозах при выборке из основной таблицы пользователе?

dixi

 nostalgie
Тьфу блин.. там primary и key

key все-таки стоит убрать

 nostalgie
Тьфу блин.. там primary и key

key все-таки стоит убрать

 leroy_17
если ставишь varchar ставь их кратным 2, если место не жалко то ставь char Для некоторых полей например ICQ , работать будет быстрее но база будет намного больше,


ну и самое главное ключи поставь, как уже тут сказали, везед где можно поставь LIMIT, указывай не * а поля точно, а так запрос сам нужно видеть чтоб точно сказать

 Formator
Без запроса тебе тут никто ничего не скажет по теме. Все советуют оптимизировать поля, поставить индексы и т.п. Это всё, само собой, верно. Но может там у тебя в выборке километровое регулярное выражение, или несколько условий с подстроками, или куча джойнов - тогда никакие индексы не помогут. Может у тебя условие WHERE user_username='user' AND user_password='pass' AND user_email='e@mail' - обычно такие запросы дико тормозят даже на мелких базах. Показал бы запрос, сразу бы всё стало ясно.

Но итак видно, что таблица не очень. "`user_icq` varchar(15) default NULL" - вот это жесть конечно. Если по user_icq идёт выборка, то поле надо делать как BIGINT. Да и CHAR побыстрее VARCHAR.

Если у тебя обычный SELECT * FROM phpbb_users LIMIT 1, то тогда лучше оттюнить мускуль, отдать ему больше памяти. Проверь ещё чтобы тейбл был MyISAM. В любом случае, погляди сам, или попроси админа, переменные: table_cache, key_buffer, back_log (может ты выполняешь запрос с уже сильно нагруженной базой), sort_buffer, thread_concurrency (если многопроцессорная система) и т.п.

Ещё вариант, если ты реально ищешь по строкам и можешь подправить софт. К примеру, ты всегда ищешь по юзеру и пассу (проверка на логин, очень часто юзается) - в данном случае проще сделать хеш для каждого юзера (что-нибудь вроде crc32($username.$password)) и по нему уже искать.

 ibiz
видимо все-же запрос сложный с left join... сделал в три запроса, стало быстрее работать