Оптимизация MySQL запроса. - Visavi.net https://visavi.net/ RSS - Visavi.net https://visavi.net/assets/img/images/logo_small.png RSS - Visavi.net https://visavi.net/ [email protected] (admin) [email protected] (admin) Sat, 21 Sep 2024 10:36:21 +0300 36. <strong>Башка</strong>, нннда, не высокого же ты о себе мнения, балда) https://visavi.net/topics/37960/636288 Оптимизация MySQL запроса. Момору Tue, 28 May 2013 18:31:17 +0400 Сообщения https://visavi.net/topics/37960/636288 ))) это не тонко, это глупо https://visavi.net/topics/37960/636238 Оптимизация MySQL запроса. Артур Mon, 27 May 2013 21:56:11 +0400 Сообщения https://visavi.net/topics/37960/636238 34. <strong>Башка</strong>, ты что, только нить уловил? Ба, Эйнштейн. https://visavi.net/topics/37960/636237 Оптимизация MySQL запроса. Момору Mon, 27 May 2013 21:51:59 +0400 Сообщения https://visavi.net/topics/37960/636237 33. <strong>JaKazanova</strong>, мы тут про СУБД разговариваем https://visavi.net/topics/37960/636236 Оптимизация MySQL запроса. Артур Mon, 27 May 2013 21:47:48 +0400 Сообщения https://visavi.net/topics/37960/636236 27. <strong>Башка</strong>, ваша логика не логична. Правильно девка говорила, не те книги читаете. А регистратор медленно-тяжелых запросов именно там и находится, на стороне сервера баз. Откройте его и посмотрите, все ваши звездочки фиксируются в нем. Или как там выше было сказано &quot;ламмерских запросов&quot;? Опять с ней согласен. Я понимаю, что вами правит коллективный разум зараженный стадным инстинктом, но не стоит же отридцать очевидные вещи. Все, я офф, грызитесь дальше) https://visavi.net/topics/37960/636235 Оптимизация MySQL запроса. Момору Mon, 27 May 2013 21:30:46 +0400 Сообщения https://visavi.net/topics/37960/636235 <blockquote class="blockquote"><strong>Ant0ha</strong> (27 Мая 2013 / 03:37)<br> А мне весело почитать сообщения госпожи erika, очень так интересно.)</blockquote> Наталкивает на размышления о смысле жизни?<img src="https://visavi.net/uploads/stickers/smile.gif" alt="smile"> https://visavi.net/topics/37960/636211 Оптимизация MySQL запроса. Zдешний Mon, 27 May 2013 14:54:19 +0400 Сообщения https://visavi.net/topics/37960/636211 А мне весело почитать сообщения госпожи erika, очень так интересно.) https://visavi.net/topics/37960/636189 Оптимизация MySQL запроса. Ant0ha Mon, 27 May 2013 01:37:26 +0400 Сообщения https://visavi.net/topics/37960/636189 19. <strong>erika</strong>, вы ведь вкурсе, что A..I расшифровывается как auto_increment? а то зачем тогда мое последнее: &quot;A..I это не касается правда.&quot;, расписывать на целый абзац? самой себе объясняете? https://visavi.net/topics/37960/636187 Оптимизация MySQL запроса. Вячеслав Mon, 27 May 2013 00:44:28 +0400 Сообщения https://visavi.net/topics/37960/636187 А вообще тонкий засчитан ))) +1<br> <br> <em><span style="font-size:x-small">Добавлено через 07:11 сек.</span></em><br> <blockquote class="blockquote"><strong>erika</strong> (26 Мая 2013 / 20:19)<br> 19. <strong>Trionix</strong>, верно инструкция NOT NULL в теле ячейки и выражение FOREIGN KEY (....) REFERENCES ... (....) создана для кого то более умного и не столь закоренелого в своей глупости нежели Вы. Включите мозги, и хоть раз в жизни пошевелите ими. Какая опирация выполнится скорее. Подщет ячеек таблицы по значению одного поля или всех существующих. Неужели результат выполнения не будет тем же но, скорость выполнения данной операции с учетом вложенности таблицы 10000000 и более элементов увеличится в несколько раз. По моему, это так же логично, как и то, что сейчас день. Но несколькими часами позже наступит ночь, этому никто не удивится. Потому что это закономерно.</blockquote> А при чем тут предположения если есть вполне себе описанные механизмы обработки.<br> Эрика, если вы говорите серьезно, то я в шоках, иначе я поддерживаю столь тонкий подход ))) https://visavi.net/topics/37960/636182 Оптимизация MySQL запроса. Артур Sun, 26 May 2013 23:58:13 +0400 Сообщения https://visavi.net/topics/37960/636182 27. <strong>Башка</strong>, вот так уж да! Вот это я понимаю, поставить на место! Респект! А за объяснения - отдельное спасобо https://visavi.net/topics/37960/636178 Оптимизация MySQL запроса. Eyler Sun, 26 May 2013 23:34:19 +0400 Сообщения https://visavi.net/topics/37960/636178 14. <strong>erika</strong>, мне кажется (возможно и я ошибаюсь), что я вполне очевидно ответил на мысль:<br> erika (26 Мая 2013 / 04:52)<br> Выводите в SELECT не звездочкой, а только имена нужных Вам полей перечисленных через запятую<br> <br> Вы, товарищ, говорите что если необходимо в операции SELECT вывести поля, то нужно указывать их, а я спросил - что если мне нужны все поля? - более того, если я использую динамическую таблицу, как мне вывести все поля? Более того, если бы вы перестали читать тупые Русские книги по СУБД и нацелили свое внимание на более-менее серьезную литературу лиц, являющихся, собственно, авторами реляционных СУБД, то вы бы поняли, что выборка всех полей таблицы это наименее затратная операция, нежели разделение поля на части. Как то так<br> <br> <em><span style="font-size:x-small">Добавлено через 04:56 сек.</span></em><br> А теперь давайте займемся изучением реляционных СУБД и принципов их работы. Дело в том, что любая, таблице-ориентированная база данных оперирует с такими понятиями, как &quot;запись&quot;. Следует сразу отметить, что выборка Записи есть одна операция, а выборка поля записи, есть более одной операции, следовательно выборка определенных полей при SELECT есть более ресурсозатратная операция, нежели *, отсюда следует, что сложность алгоритма выборки полей есть O^n где n - есть число полей запроса.<br> <br> Пойдем далее. Операция COUNT (ориентируясь на алгоритмы MySQL) подсчитывает число компонентов указателя Записей, следовательно предварительная выборка полей Записи есть дополнительные n операций к операции подсчета записей COUNT. Продолжать?<br> <br> <em><span style="font-size:x-small">Добавлено через 07:32 сек.</span></em><br> Если некто сомневается в моих высказываниях, следует отметить следующее: каждое поле таблицы, в которой производится выборка, есть логическая группировка данных по их размеру, типу и имени. Следовательно запись данных есть более простая структура, нежели некоторое поле. Следовательно разбиение запроса по полям есть более ресурсозатратная операция, с другой стороны, менее емкая относительно возвращаемых данных, что в локалхост, не имеет никакого значения. Я кончил https://visavi.net/topics/37960/636172 Оптимизация MySQL запроса. Артур Sun, 26 May 2013 22:52:56 +0400 Сообщения https://visavi.net/topics/37960/636172 <blockquote class="blockquote"><strong>erika</strong> (26 Мая 2013 / 22:21)<br> 23. <strong>Flyd</strong>, пошли сьезды по теме, это все слишком суровая прямота ваших не многочисленных извилин сказывается. Приймите к сведению, со здоровьем шутки плохи)</blockquote> неа, апломб твой сказывается https://visavi.net/topics/37960/636171 Оптимизация MySQL запроса. Михаил Sun, 26 May 2013 22:34:09 +0400 Сообщения https://visavi.net/topics/37960/636171 23. <strong>Flyd</strong>, пошли сьезды по теме, это все слишком суровая прямота ваших не многочисленных извилин сказывается. Приймите к сведению, со здоровьем шутки плохи) https://visavi.net/topics/37960/636170 Оптимизация MySQL запроса. Erika Sun, 26 May 2013 22:21:31 +0400 Сообщения https://visavi.net/topics/37960/636170 <blockquote class="blockquote"><strong>erika</strong> (26 Мая 2013 / 21:10)<br> 16. <strong>Zдешний</strong>, чти в предведущих постах, там все сказано.</blockquote> Давно прочел. Спасибо за ответ, не ожидал https://visavi.net/topics/37960/636166 Оптимизация MySQL запроса. Zдешний Sun, 26 May 2013 21:59:55 +0400 Сообщения https://visavi.net/topics/37960/636166 <blockquote class="blockquote"><strong>erika</strong> (26 Мая 2013 / 20:30)<br> ...и рюкзак знаний хрупкие девичьи плечи не оттягивает, отнюдь)</blockquote> Странно. Значит ПМС или недотрах https://visavi.net/topics/37960/636157 Оптимизация MySQL запроса. Михаил Sun, 26 May 2013 20:33:03 +0400 Сообщения https://visavi.net/topics/37960/636157