Оптимизация MySQL запроса.
1. Александр (23.05.2013 / 21:37)Доброго времени суток. Пишу форум.
Цель: Вывести список фракций, с последующими колонками, Название | Кол-во тем | Кол-во сообщений | Посл. тема, Автор, Время.
Составил MySQL запрос. Все работает. Но нельзя ли его как то оптимизировать?
Сам запрос.
SELECT a.`id`, a.`name`,
( SELECT COUNT(*) FROM `forum_fthemes` WHERE `fid` = a.`id` ) AS `count_themes`,
( SELECT COUNT(*) FROM `forum_fmessages` WHERE `fid` = a.`id` ) AS `count_messages`,
( SELECT `last_author` FROM `forum_fthemes` WHERE `fid` = a.`id` ORDER BY `last_time` DESC LIMIT 1 ) AS `last_author`,
( SELECT `last_time` FROM `forum_fthemes` WHERE `fid` = a.`id` ORDER BY `last_time` DESC LIMIT 1 ) AS `last_time`,
( SELECT `title` FROM `forum_fthemes` WHERE `fid` = a.`id` ORDER BY `last_time` DESC LIMIT 1 ) AS `last_title`,
( SELECT `name` FROM `players` WHERE `id` = `last_author` LIMIT 1 ) AS `name_author`
FROM `fractions` AS a
2. JustZero (23.05.2013 / 21:54)
так не пробовал? я сам х3, не проверял
SELECT a.`id`, a.`name` (SELECT b.`last_author` AS `last_author`, b.`last_time` AS `last_time`, b.`title` AS `title`, COUNT(b.*) AS `count_themes` FROM b WHERE b.`fid` = a.`id` ORDER BY b.`last_time` DESC LIMIT 1), (SELECT COUNT(*) FROM c WHERE c.`fid` = a.`id`) AS `count_messages`, (SELECT d.`name` FROM d WHERE d.`id` = `last_author` LIMIT 1) AS `name_author` FROM fractions AS a, forum_fthemes AS b, forum_fmessages AS c, players AS d
3. Александр (24.05.2013 / 00:29)
Ошибку выдает.
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT b.`last_author` AS `last_author`, b.`last_time` AS `last_time`, b.`title`' at line 2
4. Erika (26.05.2013 / 04:52)
В место звездочек в COUNT(*) поставьте значение какого нибуть одного поля например, примака. После измерьте скорость выполнения запроса, прирост очевиден. Используйте в запросах LIMIT. Если не надо много одинаковых значений - сгруппируйте их. Еще лучше пометьте UNIQUE непосредственно в теле таблицы. Выводите в SELECT не звездочкой, а только имена нужных Вам полей перечисленных через запятую, Используйте хранимый код он быстрее выполняется. SQL на самом деле на много фукциональнее и богаче чем Вы можете себе это вообразить, молодой человек. Посему, советую изучить его глубже, воспользуйтесь специализированной литературой для этого.
Удачи в разработке. Всех Вам благ
5. Zдешний (26.05.2013 / 09:11)
erika (26 Мая 2013 / 06:52)А готовое написать?
В место звездочек в COUNT(*) поставьте значение какого нибуть одного поля например, примака. После измерьте скорость выполнения запроса, прирост очевиден. Используйте в запросах LIMIT. Если не надо много одинаковых значений - сгруппируйте их. Еще лучше пометьте UNIQUE непосредственно в теле таблицы. Выводите в SELECT не звездочкой, а только имена нужных Вам полей перечисленных через запятую, Используйте хранимый код он быстрее выполняется. SQL на самом деле на много фукциональнее и богаче чем Вы можете себе это вообразить, молодой человек. Посему, советую изучить его глубже, воспользуйтесь специализированной литературой для этого.
Удачи в разработке. Всех Вам благ
6. Вячеслав (26.05.2013 / 11:23)
4. erika
"место звездочек в COUNT(*) поставьте значение какого нибуть одного поля например, примака" - прирост не очевиден, тем более если выборка по индексу.
- - -
"Используйте в запросах LIMIT" - прии спользовании индексов (а обычно 100% использования всеми) не эффективно.
дальше и читать не стал.. где такой ерунды набрались?
7. Erika (26.05.2013 / 12:15)
6. Trionix, видимо Вы не дружите с книгами, не в курсе, что на каждый запрос выделяется определенный лимит времени и памяти. А запросы со звездочками автоматически регистрируются системой в журнале ламмерских запросов сервера БД. Это, как звонок пожарной сигнализации на который, опытный и аккуратный программист не может не обратить пристального внимания во избежание катастроф связанных с возможными нагрузками (например ддос), в виду своего личного профессионилизма.
Давайте. Создайте еще один на обе ноги кривой дцмс (ранних версий). Вас же будут тыкать носом, с Вас же будут скромно улыбатся в усы, тихонько перешептываясь знающие люди, профессионалы. По этому мне, как соловью - извращайтесь.
PS.
Но если же Вы вдруг произошли из славного рода Страшилы Мудрого, пардон - ищите Элли. На совместных теннингах со всей ее гоп компанией, стопуя незадачливых туристов по пути к Гудвину Вы волей - не волей научитесь немного и изредка, чуток пошевеливать своими соломенными извилинами)
Добавлено через 06:36 сек.
5. Zдешний, о чем Вы?
Человек спросил совет по оптимизации горбатого кода - я его дала. Возможно в этой отрасли институтов я не заканчивала, но книг на своем веку прочла не мало. По этому его по праву можно назвать авторитетным.
Возможно Вас интересуют какие нибуть конкретные моменты. Тогда будьте добры - уточните.
8. Вячеслав (26.05.2013 / 12:30)
7. erika, читать умею. например вот: http://www.mysqlperformanceblog.com/2007/04/10/count-vs-countcol/, а то мне ведь не верите. все же, где можно почитать вашу ерунду?
9. Erika (26.05.2013 / 12:38)
8. Trionix, возьмите любую книгу по администрированию СУРБД. И прочтите то что на первый взгляд Вам покажется самым не интересным.
По поводу статьи по ссылке. Взглянув на примеры кодов - читать не стала.
PS.
И еще одно, позвольте узнать, почему это личное мнение какого то мистера Зайцева я должна ставить выше вот этой кгиги ?
10. Вячеслав (26.05.2013 / 13:16)
9. erika, About Peter Zaitsev
Peter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.
- - -
иметь книгу на полке, знать ее содержание, уметь применять знания из книги - 3 разных вещи. спс за ссылку. еще бы страницу в книге, где говорится о вашем мнении.
11. Erika (26.05.2013 / 13:39)
10. Trionix, жесть, а я вице президент Майкрософт, что называется сразу после Билли. Гг)
Может мне за Вас еще и код настропать? Если Вы читаете текст книги выборочно, мне Вас искренне жаль. В ней то и поиск по словосочетанию воспрещен, специально от подобных неуков. Могу еще с десяток книг подкинуть, если хотите. И все они прочтены от корки до корки, уверяю Вас.
----
Коли Вы считаете себя столь умным, к чему тогда весь этот цирк с оптимизацией горбатого кода, что за танцы с бубном? Дело Ваше, катайтесь на велике без колес.
12. Артур (26.05.2013 / 14:49)
erika (26 Мая 2013 / 04:52)А если мне нужны все поля таблицы?
Выводите в SELECT не звездочкой, а только имена нужных Вам полей перечисленных через запятую
13. Eyler (26.05.2013 / 15:19)
11. erika, неадекватность и грубость в постах. Вы кем себя возомнили? Гуру всего?
14. Erika (26.05.2013 / 15:56)
12. Башка, все поля в счетчике? Хм, что то новое, просветите
Добавлено через 03:18 сек.
13. Eyler, о Ваших велосипедах я стараюсь вобще не вспоминать, особенно перед сном.
15. muhamed (26.05.2013 / 16:10)
я установил скрипт на hostinger все нормально а на h2m php my admin выдает ошибку
Ошибка
SQL-запрос:
--
-- Table structure for table `admins`
--
DROP TABLE IF EXISTS `admins` ;
Ответ MySQL:
#1046 - No database selected что это значит
16. Zдешний (26.05.2013 / 17:35)
7. erika, мне кажется, что высокомерна ты слишком стала. Диплом то по знаниям sql есть?
17. Eyler (26.05.2013 / 17:51)
7. велосипеды от того что только учусь, а вот у Вас, мне кажеться или ЧСВ шкалит, или ПМС
18. Erika (26.05.2013 / 19:10)
16. Zдешний, чти в предведущих постах, там все сказано.
19. Вячеслав (26.05.2013 / 19:53)
14.
erika,все поля в счетчике? Хм, что то новое, просветитеподсчет по определенной ячейке (COUNT(`id`)) может выдать неверный результат. ведь вполне возможно, что эта ячейка может иметь пустое значение или NULL - попросту не засчитываются такие строки при подсчете. A..I это не касается правда.
20. Erika (26.05.2013 / 20:19)
19. Trionix, верно инструкция NOT NULL в теле ячейки и выражение FOREIGN KEY (....) REFERENCES ... (....) создана для кого то более умного и не столь закоренелого в своей глупости нежели Вы. Включите мозги, и хоть раз в жизни пошевелите ими. Какая опирация выполнится скорее. Подщет ячеек таблицы по значению одного поля или всех существующих. Неужели результат выполнения не будет тем же но, скорость выполнения данной операции с учетом вложенности таблицы 10000000 и более элементов увеличится в несколько раз. По моему, это так же логично, как и то, что сейчас день. Но несколькими часами позже наступит ночь, этому никто не удивится. Потому что это закономерно.
И это, значение полей типа SERIAL (INNODB), AUTO_INCREMENT (MYISAM) автоматически становится BIGINT UNSIGNED NOT NULL, и UNIQUE если его обьявить в качестве первичного ключа. Молодой человек, книги пишуть для людей, таких как мы с Вами. Помните об этом, пользуйтесь этим.
На этом дискуссия окончена. Подобные перепитии засоряют мне карму.
Всех благ Вам
21. Михаил (26.05.2013 / 20:26)
20. erika, тебе корона не давит?
22. Erika (26.05.2013 / 20:30)
...и рюкзак знаний хрупкие девичьи плечи не оттягивает, отнюдь)
23. Михаил (26.05.2013 / 20:33)
erika (26 Мая 2013 / 20:30)Странно. Значит ПМС или недотрах
...и рюкзак знаний хрупкие девичьи плечи не оттягивает, отнюдь)
24. Zдешний (26.05.2013 / 21:59)
erika (26 Мая 2013 / 21:10)Давно прочел. Спасибо за ответ, не ожидал
16. Zдешний, чти в предведущих постах, там все сказано.
25. Erika (26.05.2013 / 22:21)
23. Flyd, пошли сьезды по теме, это все слишком суровая прямота ваших не многочисленных извилин сказывается. Приймите к сведению, со здоровьем шутки плохи)
26. Михаил (26.05.2013 / 22:34)
erika (26 Мая 2013 / 22:21)неа, апломб твой сказывается
23. Flyd, пошли сьезды по теме, это все слишком суровая прямота ваших не многочисленных извилин сказывается. Приймите к сведению, со здоровьем шутки плохи)
27. Артур (26.05.2013 / 22:52)
14. erika, мне кажется (возможно и я ошибаюсь), что я вполне очевидно ответил на мысль:
erika (26 Мая 2013 / 04:52)
Выводите в SELECT не звездочкой, а только имена нужных Вам полей перечисленных через запятую
Вы, товарищ, говорите что если необходимо в операции SELECT вывести поля, то нужно указывать их, а я спросил - что если мне нужны все поля? - более того, если я использую динамическую таблицу, как мне вывести все поля? Более того, если бы вы перестали читать тупые Русские книги по СУБД и нацелили свое внимание на более-менее серьезную литературу лиц, являющихся, собственно, авторами реляционных СУБД, то вы бы поняли, что выборка всех полей таблицы это наименее затратная операция, нежели разделение поля на части. Как то так
Добавлено через 04:56 сек.
А теперь давайте займемся изучением реляционных СУБД и принципов их работы. Дело в том, что любая, таблице-ориентированная база данных оперирует с такими понятиями, как "запись". Следует сразу отметить, что выборка Записи есть одна операция, а выборка поля записи, есть более одной операции, следовательно выборка определенных полей при SELECT есть более ресурсозатратная операция, нежели *, отсюда следует, что сложность алгоритма выборки полей есть O^n где n - есть число полей запроса.
Пойдем далее. Операция COUNT (ориентируясь на алгоритмы MySQL) подсчитывает число компонентов указателя Записей, следовательно предварительная выборка полей Записи есть дополнительные n операций к операции подсчета записей COUNT. Продолжать?
Добавлено через 07:32 сек.
Если некто сомневается в моих высказываниях, следует отметить следующее: каждое поле таблицы, в которой производится выборка, есть логическая группировка данных по их размеру, типу и имени. Следовательно запись данных есть более простая структура, нежели некоторое поле. Следовательно разбиение запроса по полям есть более ресурсозатратная операция, с другой стороны, менее емкая относительно возвращаемых данных, что в локалхост, не имеет никакого значения. Я кончил
28. Eyler (26.05.2013 / 23:34)
27. Башка, вот так уж да! Вот это я понимаю, поставить на место! Респект! А за объяснения - отдельное спасобо
29. Артур (26.05.2013 / 23:58)
А вообще тонкий засчитан ))) +1
Добавлено через 07:11 сек.
erika (26 Мая 2013 / 20:19)А при чем тут предположения если есть вполне себе описанные механизмы обработки.
19. Trionix, верно инструкция NOT NULL в теле ячейки и выражение FOREIGN KEY (....) REFERENCES ... (....) создана для кого то более умного и не столь закоренелого в своей глупости нежели Вы. Включите мозги, и хоть раз в жизни пошевелите ими. Какая опирация выполнится скорее. Подщет ячеек таблицы по значению одного поля или всех существующих. Неужели результат выполнения не будет тем же но, скорость выполнения данной операции с учетом вложенности таблицы 10000000 и более элементов увеличится в несколько раз. По моему, это так же логично, как и то, что сейчас день. Но несколькими часами позже наступит ночь, этому никто не удивится. Потому что это закономерно.
Эрика, если вы говорите серьезно, то я в шоках, иначе я поддерживаю столь тонкий подход )))
30. Вячеслав (27.05.2013 / 00:44)
19. erika, вы ведь вкурсе, что A..I расшифровывается как auto_increment? а то зачем тогда мое последнее: "A..I это не касается правда.", расписывать на целый абзац? самой себе объясняете?
31. Ant0ha (27.05.2013 / 01:37)
А мне весело почитать сообщения госпожи erika, очень так интересно.)
32. Zдешний (27.05.2013 / 14:54)
Ant0ha (27 Мая 2013 / 03:37)Наталкивает на размышления о смысле жизни?
А мне весело почитать сообщения госпожи erika, очень так интересно.)
33. Момору (27.05.2013 / 21:30)
27. Башка, ваша логика не логична. Правильно девка говорила, не те книги читаете. А регистратор медленно-тяжелых запросов именно там и находится, на стороне сервера баз. Откройте его и посмотрите, все ваши звездочки фиксируются в нем. Или как там выше было сказано "ламмерских запросов"? Опять с ней согласен. Я понимаю, что вами правит коллективный разум зараженный стадным инстинктом, но не стоит же отридцать очевидные вещи. Все, я офф, грызитесь дальше)
34. Артур (27.05.2013 / 21:47)
33. JaKazanova, мы тут про СУБД разговариваем
35. Момору (27.05.2013 / 21:51)
34. Башка, ты что, только нить уловил? Ба, Эйнштейн.
36. Артур (27.05.2013 / 21:56)
))) это не тонко, это глупо
37. Момору (28.05.2013 / 18:31)
36. Башка, нннда, не высокого же ты о себе мнения, балда)
URL: https://visavi.net/topics/37960