mysql+150000 записей+размер 500МБ. Вешается :)

Вот это?

Можно расписать, что такое "id>" и откуда я его возьму? :)

---------- Добавлено 24.02.2012 в 13:28 ----------

Чёт я не врубаюсь смотрю запрос выполняется 27 секунд:

Query 27 Sorting result SELECT id FROM `cms_freepages` WHERE cat=11 ORDER BY ID

Через phpmyadmin c SQL_NO_CACHE 0,005 секунд

Я что-то не понимаю в этой жизни? :)

зависит от размера категории. на php нужно стараться по максимуму использовать встроенные функции, они же на Cи написаны. И не крутить циклов.

предложение iopiop прекрасно, но подразумевает вообще другой принцип листания и вообще его уже предлагали.

Посмотрели бы уже план. Скорее всего 11 категория самая большая и он решил перебрать всю таблицу.

Да это глупости какие-то. Он самая маленькая.

Я уже убрал сортировку:

SELECT SQL_NO_CACHE id FROM `cms_freepages` WHERE cat =11

Отображает строки 0 - 29 ( 3,228 всего, запрос занял 0.0009 сек.)

EXPLAIN

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE cms_freepages ref cat cat 4 const 3517

т.е. как бы всё очень быстро через phpmyadmin и все довольны.

Может тут что-то не так my.cnf на машине 2 ГБ памяти и 4-ре ядра.

[mysqld]

max_connections=150

safe-show-database

skip-locking

skip-innodb

skip-networking

safe-show-database

skip-name-resolve

skip-external-locking

query_cache_limit=2M

query_cache_size=128M

query_cache_type=1

max_user_connections=150

interactive_timeout=10

wait_timeout=20

connect_timeout=20

thread_cache_size=128

join_buffer_size=2M

max_connect_errors=9999999

max_allowed_packet=1M

table_cache=1024

tmp_table_size=128M

max_join_size=1000000

record_buffer=1M

sort_buffer_size=2M ## 1MB for every 1GB of RAM

read_buffer_size=2M ## 1MB for every 1GB of RAM

read_rnd_buffer_size=2M ## 1MB for every 1GB of RAM

thread_concurrency=12 ## Number of CPUs x 2

myisam_sort_buffer_size=64M

max_heap_table_size=65M

join_buffer_size=2M

key_buffer_size=300M

table_open_cache = 256

table_cache=300

table_definition_cache=300

log_queries_not_using_indexes

#log_slave_updates

log_long_format

[isamchk]

key_buffer=128M

sort_buffer=128M

read_buffer=32M

write_buffer=32M

[myisamchk]

key_buffer=128M

sort_buffer=128M

read_buffer=32M

write_buffer=32M

Интересная тема.

Я почитаю и дождусь решения, если Вы не против :)

LEOnidUKG, смысла смотреть конфиг без всех остальных данных о сервере нет. Всех остальных, которых ты все равно не знаешь как показать. И данные о сортировках противоречивые приводишь.

Пиши уже и как-нибудь опытным путем найдешь что быстрее.

Конечно уважаемый, продолжайте и дальше морочить людям голову.

Ни структуры таблицы не показали, ни explain запроса из первого поста.

И правильно, зачем, пусть телепаты напрягаются.

Так легче стало на душе?

Отображает строки 6150 - 6179 ( 6,247 всего, запрос занял 6.7226 сек.)

SELECT *

FROM `cms_freepages`

WHERE `cat` =4

LIMIT 6150 , 30

EXPLAIN:

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE cms_freepages ref cat cat 4 const 6892

LEOnidUKG, у нас уже есть острое ощущение, что у Вас диски на сервере накрываются или типа того.

На нормальном сервере с теми настройками и данными что Вы привели - время запроса по 6.7 секунд - чисто фантастика и абсолютно не норма. Или может у Вас триггеры какие-то на этих таблицах висят там... Ради интереса сделали аналогичные выборки у себя на полудохлом вдс от хетзнера за 10 баксов, все запросы укладываются в 1 секунду, те что у Вас по 4-5 на выделенном крутом серваке.

Жестак новый, как и сервак. Тут проблема, что жестак очень нагружен, а вот кем, мы с админов не выяснили.

Поэтому придётся вырубать в слепую всякие форму и т.п.

LEOnidUKG, нет так не лучше - все равно не видно как именно созданы индексы. обычно используют оператор show create table XXX; потом show index from XXX. Планы EXPLAIN, реальное количество затронутых строк в разнице SHOW STATUS и вообще еще кучу инструментов.

Если не хотите вслепую мыкаться, то надо все это изучить. И администратору так и передайте.

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