Это с text полем или без него? В теме уже фигурировали оба запроса, но между ними серьёзная разница.
Для text ещё объяснимо, сортировка датасета с text - это всегда дисковая сортировка. А без него - запрос должен нормально жить.
ох, точно, тестировал на select * from..., совсем забыл про поля. сам текст не нужен. Стало 0.2 - 0.4 сек - и это тоже на сортировку все время ушло.
Странно, утром и днем наблюдал, что почему то эти запросы были очень долгие 1-2 секунды, и пользователи в последнее время стали жаловаться, что сайт часто начал висеть. Буду искать далее слабые места, спасибо, что помогли, профайлер - вещь, не знал о нем
в phpmyadmin использовал Profiler
по id запрос выполняется быстро. sorting result 1.9 s
Вообщем, проверил 10 запросов, затраты на sorting result составляют почти все время (от 0.1 сек до 2 сек). Почему же так долго, может потому большой объем извлекается? некоторые главы в сумме составляют мегабайт текста.
наверно придется отказаться от order by, а сортировку делать средствами php.
есть ли способы это улучшить?
explain?Сколько в таблице записей с таким book_id?
По разному. в textbooks хранятся главы книг с текстом, у книги может быть одна глава, а то и 50. Ну в среднем 15 записей по определенному book_id/
Мелкий пишет:
Сколько из них с status = 1?
Я перепутал, status = 0. Это означает глава не удалена, удаленных глав почти нет, но изредка главы удаляются, поэтому и запрос такой. Так что, очень мало. в 99% случаев status = 0, 1% status = 0. (Добавление)
может быть проблема в том, что я неправильно организовал все...
Таблица textbooks содержит столбцы id, title (название главы), text_of_chapter (сам текст главы, иногда там хранится 1мб текста),status.
Запросом, который я привел выше, я просто вытаскиваю оглавление (нужны только title), но не текст. Наверно надо будет эту таблицу разбить на две таблицы: главы; текст главы.
Всем привет, есть таблица textbooks размером 1.1 гигабайт
К ней обращаются по такому запросу
select id, title from texbooks where book_id = 112233 and status = 1 order by id desc
индекс стоит на поле book_id.
В последнее время бд начала нехило тормозить, ищу проблему, а этот запрос начал тормозить 1-2 секунды выполнения, вот и решил его исследовать.
должен ли такой запрос выполнятся долго? можно ли как то улучшить запрос?
я думаю, что этот запрос не должен выполнятся долго. вроде, бд должна сначала должна вытащить записи по запросу where book_id = 112233 т.к. на нем индекс, то есть быстро, и по полученным записям сделать вторую выборку status = 1 и их отсортировать order by.
или status = 1 заставит БД пройтись по всей таблице??
БД mysql
INSERTINTO tag_book (tag_id, book_id)SELECT id, 777 FROM tags WHERE name="хлеб"
Но ваш запрос выглядит тоже рабочим, в чём проявляется его "не работает"?
спасибо. Мой код вставлял значение 0 в поле book_id, или в tag_id, забыл хотя теги в таблице присутствовали. А ещё код вставлял только одну запись, даже если выборка большая select id from tags where name="хлеб" or name = "еще"
Какая база данных и версия?
Где explain analyze / explain extended / explain?
В старых версиях mysql был у оптимизатора баг, приводящий именно вот к такому поведению:
Еугений пишет:
второй запрос будет выполняться запрос столько раз, сколько всего у меня постов
В актуальных вроде починили.
Еугений пишет:
posts LEFT JOIN comments ... WHERE ... comments.DATA >
Почему-то очень популярная логическая ошибка писать LEFT JOIN, но потом фильтровать по этой таблице без учёта NULL. Т.е. в реальности делать INNER JOIN и при этом мешать оптимизатору.
SELECT version 5.1.68-cll-lve , Mysql
Старая, да? Похоже на хостинге надо вручную обновлять.
SELECT comments.*FROM posts LEFTJOIN comments AS c ON posts.id = comments.post_id WHERE post.user_id = МОЁ_ID AND comments.DATA> now()- interval 2 week
SELECT*FROM comments WHERE post_id IN(SELECT id FROM post WHERE user_id = МОЁ_ID)ANDDATA> now()- interval 2 week
Какой запрос лучше выбрать?
Проверил на скорость, первый запрос выполнилс за 0.06 сек а второй 0.4 А я думал первый будет долго выполняться, так там left join. А я то думал они почти одинаково прочесывают БД. Прокоментируйте пожалуйста, почему? (Добавление)
второй запрос будет выполняться запрос столько раз, сколько всего у меня постов? А я думал, мускул получит id-шки постов одним запросом, а вторым получит комменты к ним
я бы попробовал вариант разбивать книгу на логические элементы, например главы/параграфы/предложения и для каждой единицы хранить объем. когда пользователь запрашивает книгу, ему выдаются от 1 до N элементов помещающихся в их буфер (страницу) и таким образом пагинация будет не классической, а подгружать элементы начиная с максимального который отображается на странице
Разбивать главы - вы имеете ввиду, разбить текст на несколько частей и эти части хранить в отдельной таблице? Или вы про использование substring()? Этой функцией я готов срезать текст даже в середине слова, красота тут не важна, Аяксом догрузится продолжение, пользователь даже не заметит
Всем привет, на сайте люди читают книги, и я решил большой текст глав выгружать по частям, с помощью substring() (БД mysql) .
Сначала хотел так: узнаю кол-во символов в тексте с помощью char_length() и, если текст большой,делаю substring(textbook,1, Book::limit).
Но я решил, уберу-ка я запрос на получении длины,и любой текст, независимо от того, большой он или нет, буду сразу обрабатывать substring-ом. (если кол-во символов полученного текста равно Book::limit, то можно предположить, что есть текст далее и добавляю пагинацию на след.страницу)
Что выбрать? Я не знаю, как повлияет на нагрузку этот substring, сильно ли будет нагружать БД? ( примерно 5000 книг читают в день). Какой способ выбрать? Мне главное чтоб БД не грузило, ресурсы иногда закаливают.
У меня есть для писателей, 800 человек/сутки, ~15000. просмотров в день. Проблема такая, что иногда забивается оперативная память (256 МБ).
Я думаю проблема в том, что у некоторых произведения огромные. Книги можно читать двумя способами: 1)по главам, с пагинацией, 2)сразу загрузить всю книгу и читать как электронную книгу в удобном виде как в adobe reader листая влево/вправо, не скролля, как в первом способе.
Как я уже говорил, у некоторых главы огромные. 100кб-1мб.
Мне пришла мысль загружать текст по частям, добавив кнопку "загрузить далее" после сокращенного текста. Для этого мне понадобится функция substring. Я хочу всегда, перед изъятием текста использовать эту функцию, потом Аяксом подгружать пользователю продолжение, если есть.
Так вот вопросы: 1) Поможет ли мне это сократить расходы на память? 2) Будет ли эта функция сильно напрягать процессор? Долго ли будет выполнятся запрос? Все таки иногда придётся работать с большим текстом. (Добавление)
Ещё проблема может быть в том, что после изъятия текста в нем идёт замена тегов типа [center], [b] , [img].Наверно тяжёлая операция. Но после substring наверное легче будет.
Больше не могу знать в чем проблема. Запросов на страницу мало, сайт без прибамбасов.
primary key - это уникальный индекс.
Если говорить про mysql и innodb - то данные в таблице лежат неотрывно от первичного индекса. И все другие индексы ссылаются на первичный ключ, а не на непосредственно данные.
выборка постов по тегу - tag_id & post_id
выборка тегов к посту: post_id & tag_id
Если один из этих индексов сделать первичным, то второй индекс из-за свойств первичного ключа можно сократить только до первого поля. Например, tag & post - PK, и отдельно индекс по post_id.
Какой именно сделать первичным - собственно, определяющего значения не имеет.
Если я сделаю только РК, который добавляется как то так primary (tag_id, post_id) , то выборка после этого будет быстра только по полю tag_id? и поэтому надо бы добавить еще отдельно индекс на post_id?
Работаю над реализацией тегов, добавил две таблицы tags (id, tag_name) , tag_to_post (tag_id, post_id)
Вот теперь думаю как правильно добавить индексы, вроде в них в данном случае нуждается только таблица tag_to_post.
Два запроса , которые будут использоваться, это выборка постов по тегу, и получения списка тегов к каждому посту.
Какая самая выигрышная в плане и скорости нагрузки расстановка индексов? Хватит ли одного индекса на tag_id или на post_id в таблице tag_to_post? Или совместный индекс?
а если я на оба повешу primary key, то это отразиться на скорости? Это тоже индексирование?
Делаю новую страницу на своём сайте для
пользователей, так получается что там будет
запрос с двумя join (вот
набросок,упрощённый, без where):
SELECT *
FROM t1
LEFT JOIN t2 ON t1.post_id = t2.post_id
INNER JOIN t3 ON t2.post_id = t3.id
Таблицы t1 и t2 очень малы, несколько КБ, три
столбца в каждом и все integer. А вот t3
внушительна, растёт каждый день.
Я не разбираюсь в запросах, и вообще в
mysql.. Но знаю что джоины нехило могут
грузить сервер, и не рекомендуется их
выполнять на частозаходимых страницах, что
я хочу сделать
Как работает этот запрос с точки зрения БД?
Мне кажется так: сначала t1 left join t2 найдёт
необходимые id-шники, их будет немного,
0-100 штук, а уж только потом mysql
возьмется за t3. Если mysql начнёт перебирать
t3 в последнюю очередь, с готовыми id-
шками, то запрос будет не таким уж
серьёзным. Так ведь?
Или mysql в каждом своем цикле работает
сразу со всеми тремя таблицами? Если это
так то я лучше переделаю запрос на
select * from t3 where id in(select t2.post_id from
t1 left join t2 on..)
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 176
Проверил на скорость, первый запрос выполнилс за 0.06 сек а второй 0.4 А я думал первый будет долго выполняться, так там left join. А я то думал они почти одинаково прочесывают БД. Прокоментируйте пожалуйста, почему?
