Оптимизация MySQL запроса.

20. erika, тебе корона не давит?

...и рюкзак знаний хрупкие девичьи плечи не оттягивает, отнюдь)

erika (26 Мая 2013 / 20:30)
...и рюкзак знаний хрупкие девичьи плечи не оттягивает, отнюдь)

Странно. Значит ПМС или недотрах

erika (26 Мая 2013 / 21:10)
16. Zдешний, чти в предведущих постах, там все сказано.

Давно прочел. Спасибо за ответ, не ожидал

23. Flyd, пошли сьезды по теме, это все слишком суровая прямота ваших не многочисленных извилин сказывается. Приймите к сведению, со здоровьем шутки плохи)

erika (26 Мая 2013 / 22:21)
23. Flyd, пошли сьезды по теме, это все слишком суровая прямота ваших не многочисленных извилин сказывается. Приймите к сведению, со здоровьем шутки плохи)

неа, апломб твой сказывается

14. erika, мне кажется (возможно и я ошибаюсь), что я вполне очевидно ответил на мысль:
erika (26 Мая 2013 / 04:52)
Выводите в SELECT не звездочкой, а только имена нужных Вам полей перечисленных через запятую

Вы, товарищ, говорите что если необходимо в операции SELECT вывести поля, то нужно указывать их, а я спросил - что если мне нужны все поля? - более того, если я использую динамическую таблицу, как мне вывести все поля? Более того, если бы вы перестали читать тупые Русские книги по СУБД и нацелили свое внимание на более-менее серьезную литературу лиц, являющихся, собственно, авторами реляционных СУБД, то вы бы поняли, что выборка всех полей таблицы это наименее затратная операция, нежели разделение поля на части. Как то так

Добавлено через 04:56 сек.
А теперь давайте займемся изучением реляционных СУБД и принципов их работы. Дело в том, что любая, таблице-ориентированная база данных оперирует с такими понятиями, как "запись". Следует сразу отметить, что выборка Записи есть одна операция, а выборка поля записи, есть более одной операции, следовательно выборка определенных полей при SELECT есть более ресурсозатратная операция, нежели *, отсюда следует, что сложность алгоритма выборки полей есть O^n где n - есть число полей запроса.

Пойдем далее. Операция COUNT (ориентируясь на алгоритмы MySQL) подсчитывает число компонентов указателя Записей, следовательно предварительная выборка полей Записи есть дополнительные n операций к операции подсчета записей COUNT. Продолжать?

Добавлено через 07:32 сек.
Если некто сомневается в моих высказываниях, следует отметить следующее: каждое поле таблицы, в которой производится выборка, есть логическая группировка данных по их размеру, типу и имени. Следовательно запись данных есть более простая структура, нежели некоторое поле. Следовательно разбиение запроса по полям есть более ресурсозатратная операция, с другой стороны, менее емкая относительно возвращаемых данных, что в локалхост, не имеет никакого значения. Я кончил

27. Башка, вот так уж да! Вот это я понимаю, поставить на место! Респект! А за объяснения - отдельное спасобо

А вообще тонкий засчитан ))) +1

Добавлено через 07:11 сек.

erika (26 Мая 2013 / 20:19)
19. Trionix, верно инструкция NOT NULL в теле ячейки и выражение FOREIGN KEY (....) REFERENCES ... (....) создана для кого то более умного и не столь закоренелого в своей глупости нежели Вы. Включите мозги, и хоть раз в жизни пошевелите ими. Какая опирация выполнится скорее. Подщет ячеек таблицы по значению одного поля или всех существующих. Неужели результат выполнения не будет тем же но, скорость выполнения данной операции с учетом вложенности таблицы 10000000 и более элементов увеличится в несколько раз. По моему, это так же логично, как и то, что сейчас день. Но несколькими часами позже наступит ночь, этому никто не удивится. Потому что это закономерно.

А при чем тут предположения если есть вполне себе описанные механизмы обработки.
Эрика, если вы говорите серьезно, то я в шоках, иначе я поддерживаю столь тонкий подход )))

19. erika, вы ведь вкурсе, что A..I расшифровывается как auto_increment? а то зачем тогда мое последнее: "A..I это не касается правда.", расписывать на целый абзац? самой себе объясняете?