- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
последний вариант который я вам предложил пробовали ? И все id собирать не надо, и серверу перебирать все записи не надо
Вот это?
Можно расписать, что такое "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 категории и всё.
зависит от размера категории. на php нужно стараться по максимуму использовать встроенные функции, они же на Cи написаны. И не крутить циклов.
предложение iopiop прекрасно, но подразумевает вообще другой принцип листания и вообще его уже предлагали.
Чёт я не врубаюсь смотрю запрос выполняется 27 секунд:
Query 27 Sorting result SELECT id FROM `cms_freepages` WHERE cat=11 ORDER BY ID
Посмотрели бы уже план. Скорее всего 11 категория самая большая и он решил перебрать всю таблицу.
Посмотрели бы уже план. Скорее всего 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, смысла смотреть конфиг без всех остальных данных о сервере нет. Всех остальных, которых ты все равно не знаешь как показать. И данные о сортировках противоречивые приводишь.
Пиши уже и как-нибудь опытным путем найдешь что быстрее.
Fearful, конечно профессор, шли бы только мимо :)
Конечно уважаемый, продолжайте и дальше морочить людям голову.
Ни структуры таблицы не показали, ни explain запроса из первого поста.
И правильно, зачем, пусть телепаты напрягаются.
Конечно уважаемый, продолжайте и дальше морочить людям голову.
Ни структуры таблицы не показали, ни 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 ведь и был создан для работы вслепую чтобы избавить программиста от императивного мышления. Ничего это знать не нужно, пока оно не начнет тормозить.