Не не, новая таблица не нужна. Мой код вполне шустро работает, я его ещё подкрутил, убрал DESC ID и arsort добавил в PHP, чтобы мускуль вообще не парилась.---------- Добавлено 24.02.2012 в 21:39 ----------
С ораклом не путаете? explain plan?
А так уже писал в 3-й раз: /ru/forum/comment/10081908
:)
Он для ВСЕХ записей, как я ID то найду всех в cat=2? ещё и нужные ID возьму?
Для этого уже netwind предложил вложенный запрос, он выполняется отлично. Прочитайте верхний пост мой :)
Всё упёрлось сейчас в нагрузку на диск. С сервера убираются некоторые проекты на другой. Код прилично помогает, но просто диску пока не до мускуля и поэтому идут тормоза.
Но в любом случаи это быстрее, чем LIMIT, ещё надо проверить вложенный запросы, когда всё уляжется.
Я уже всё писал:
1. /ru/forum/comment/10081908
2. 1 раз в час
Жестак новый, как и сервак. Тут проблема, что жестак очень нагружен, а вот кем, мы с админов не выяснили.
Поэтому придётся вырубать в слепую всякие форму и т.п.
Так легче стало на душе?
Отображает строки 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
Да это глупости какие-то. Он самая маленькая.
Я уже убрал сортировку:
SELECT SQL_NO_CACHE id FROM `cms_freepages` WHERE cat =11
Отображает строки 0 - 29 ( 3,228 всего, запрос занял 0.0009 сек.)
EXPLAIN
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
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
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]
Вот это?
Можно расписать, что такое "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 секунд
Я что-то не понимаю в этой жизни? :)
netwind,iopiop, да это опять доли секунды. Тут главное быстро собрать все ID категории и всё.
Fearful, конечно профессор, шли бы только мимо :)
ввести такое?
Ну мы тем самым лишь уменьшаем сам массив, это опять же доли секунды.---------- Добавлено 24.02.2012 в 03:33 ----------
Да конечно.
1.Из мануала, Замечание:
Однако, плюсы использования mysql_unbuffered_query() имеют свою цену: вы не можете использовать функции mysql_num_rows() и mysql_data_seek() с результатом запроса, возвращённым этой функцией, пока не будут получены все ряды. Кроме того, вы должны будете обработать все ряды запроса до отправки нового запроса, используя тот же link_identifier.
2. Если мы даже применим mysql_data_seek, то нам НУЖНО количество ВСЕХ записей для составления листинга.
