Мой ответ “Сядьте и расслабьтесь :)”Действительно, существует очень много ситуаций, в которых серверпадает или не отвечает на запросы. Причем ситуации эти существуют длялюбых версий MySQL и их можно воспроизвести, обладая базовымипривилегиями для доступа к sql-серверу.

Мы часто помогаем людям исправлять ошибки в их приложениях,использующих MySQL (но положа руку на сердце можно сказать - вбольшинстве случаев они сами являются причиной некорректной работысервера) и ошибки эти очевидны.По-моему, девиз безопасности MySQL должна выглядеть так: если у васполностью закрыт доступ к серверу, вы действительно защищены. Длянекоторых видов атак не нужен валидный аккаунт, но такие ошибкидовольно быстро исправляются. В тот момент, когда вы даете кому-тоаккаунт вы перестаете полностью контролировать ситуацию. И значит, чтозащищенность сервера становится немного ниже.Такое положение вещей будет сохраняться все время, пока MySQL использует Глобальное Управление Ресурсами, и вы реально не можете контролировать количество ресурсов, доступных вашим пользователям.Вы можете возразить, что это, в принципе, не катастрофа. Конечно, носервер можно еще перегрузить и сделать его недоступным. Или заставитьMySQL использовать всю доступную память, в результате чего сервер будетпросто убит операционной системой. На 32-битных системах провестиподобные трюки гораздо легче.Дам вам несколько советов:
Временные таблицы вы можете использовать запросы спроизводными таблицами и создавать в памяти неограниченное количествовременных таблиц с неограниченным размером.Таблицы в памяти Если вы можете создать в памятиодну таблицу, значит вы можете создать любое количество. Хотя размертаблицы ограничен директивой max_heap_table_size, общий размер таблиц не ограничен никак. Вы можете создавать таблицы как TEMPORARY и их не будет в файловой системе.MyISAM Sort Buffer - обычно его размерустанавливают довольно большим, но он может одновременно работатьтолько с несколькими таблицами. А что будет, если пользовательиспользует все его дозволеные 100 подключений для инструкции ALTER для100 разных таблиц? Можно искусственно ограничить его занижениемзначения параметра myisam_sort_buffer_size, но это отразится на производительности.Количество подготовленных инструкций (Prepared Statements) - к счастью теперь есть лимит на максимальное количество подготовленных инструкций (параметр max_stmt_count),который задается сервером. Это лучше, чем было раньше, когда можно былозаставить сервер использовать всю доступную память, просто забывзакрыть подготовленные инструкции. Однако ограничения для пользователяотсутствуют и один пользователь может исчерпать весь лимит,заблокировав доступ к использованию подготовленных инструкций дляостальных. Кроме того, не все инструкции занимают одинаковое количествопамяти и подготовка сложных инструкций может отнять бoльшую часть ресурсов. Решить проблему можно, ограничив использование подготовленных инструкций и установив параметр max_prepared_stmt_count в очень низкое значение.Подготовленные инструкции и BLOB-данные - если выхотите получить память, занятую одной подготовленной инструкцией, выможете создать инструкцию с тысячей меток (placeholders) и посылатьданные каждой из них, используя вызов mysql_stmt_send_long_data. Буферы сервера будут принимать данные до тех пор, пока инструкция не будет выполнена.Утечки кэша таблиц Innodb - InnoDB никогда неограничивает размер внутренних таблиц в кеше (словарь данных). Так чтооткрывая большие таблицы и работая с ними вы можете исчерпать всюдоступную память. Обычно размер 4-8К на таблицу, но сложные таблицымогут занимать и больше. В основном это проблема небольших серверов.Кэш Слитых таблиц - кэш таблиц обычно распределен икаждая запись обычно соответствует не более, чем паре файловыхдескрипторов. Но не в случае Слитых таблиц - создание и доступ кнескольким слитым таблицам с, например, тысячей подтаблиц не лучшимобразом скажется на вашем сервере. Тоже самое относится и к Разделеннымталицам из MySQL 5.1Место на диске - для MyISAM-таблиц хостинг-провайдеры обычно используют дисковые квоты. Вы можете использовать похожий подход при помощи innodb_file_per_table.Однако вы не можете контролировать рост системных таблиц InnoDB,которые используются для хранения данных об отменах и которые могутувеличиваться с каждой открытой транзакцией и делать множествообновлений. Или просто сохранять транзакцию открытой и позволять другимпользователям делать обновления - InnoDB может только очистить данныепосле старых транзакций, нуждающихся в мгновенном коммите. Вы можетерешить этот вопрос путем уничтожения слишком старых транзакций, ноболее верным решением будет установление некоего лимита на объемхранимой информации о отменах. Еще один неплохой способ - этоиспользовать запросы с большими временными таблицами или сортировкойфайлов. Даже если временные таблицы будут храниться на другом разделе,при его переполнении другие пользователи не смогут нормально работать ссервером.Хранимые процедуры - сколько памяти можно выделитьдля хранимой процедуры? Можно создать 1000 переменных в хранимойпроцедуре и зарезервировать для каждой их них по 1М памяти. Я непроводил целенаправленных экспериментов, но думаю, что жесткой политикивыделения памяти для хранимых процедур нет.Указатели в хранимых процедурах - указатели вхранимых процедурах реализованы в виде временных таблиц. Поэтомуиспользуя большое количество указателей можно заполнить доступный объемоперативной памяти.Рекурсия в хранимых процедурах - На самом делеотличается от “классического” представления рекурсии. Это всего лишьвызовы одной процедуры из другой. Которые так же требуют выделенияпамяти и, что важно, размещаются в стеке. Есть некоторые способы длязащиты от переполнения стека, но они не могут гарантировать 100%-ногорезультата.Переменные на стороне сервера - каждый сервер имеет ограничение в виде директивы max_allowed_packet (1M по умолчанию). Но, по-видимому, нет никаких ограничений на количество создаваемых переменных.Разбор деревьев - внутренне представление запросовв MySQL выглядит как разбор дерева, которое зависит от размера запроса,который, в свою очередь, контролируется директивой max_allowed_packet.Но некоторые способы оптимизации MySQL (такие как equity propagation иrange expansion) могут привести к критическим ошибкам при анализедерева. Для нескольких тривиальных случаев такое поведение было исправлено, но вызывает сомнения, что эти исправления актуальны для всех подобных ситуаций.Сессионные переменные - нет никаких ограничений наиспользование переменных непривилегированным пользователем, которомуразрешено выполнять запросы без ограничения доступа к ресурсам.Блокировка хоста - сервер может заблокировать хостклиента из-за большого количества неудачных соединений. Этого можноизбежать, выставив большое значение для параметра max_connect_errors, но будьте осторожны: это снизит устойчивость к брутфорсу.Взаимные исключения - как InnoDB, так и MyISAMимеют “хотспоты” с несколькими соединениями. Используя их можносущественно замедлить работу сервера.Перегрузка - у MySQL нет достаточного контроля за использованием ресурсов и вы можете “положить” сервер просто выполняя тяжелые запросы. Существующие ограничения не могут полностью контролировать потребление ресурсов пользователем,поскольку не имеют механизма определения “тяжести” запроса. Тяжелыезапросы могут сильно нагрузить систему ввода/вывода и заполнить кэш ОС,что заметно снизит скорость работы сервера и запросы другихпользователей будут выполняться на порядок медленнее.Некоторые из вышеизложенных способов были испробованы на реальныхприложений, некоторые являются лишь предположением о возможномповедении сервера в случае критических ситуаций.Как вы видите, MySQL-сервер отнюдь не выглядит “пуленепробиваемым”,если кто-то намеренно будет пытаться его обрушить. Дело в том, чтобольшинство существующих ограничений (таких как max_heap_table_size или max_prepared_stmt_count) реализованы для защиты от типичных ошибок при разработке приложений, а отнюдь не от запланированной атакиПримечание: ярассмотрел лишь некоторые из объектов сервера, т.е. снижениепроизводительности при некорректной работе с каждым из них. Существуетряд глобальных квот, которые влияют на работу сервера в целом - вы неможете применить их для конкретного пользователя или соединения.P.S.: вы можетеподумать: “как же это все возможно, если существуют тысячихостинг-провайдеров, предоставляющих доступ к своим серверам БД?” Да,некоторым везт и их пользователи не создают проблем для корректнойработы MySQL, но большинству приходится “вручную” постоянноконтролировать и ограничивать пользователей, мешающих нормальномуфункционированию. Не говоря о компаниях, предоставляющих вирутальныйхостинг - там, как правило, используются старые версии ПО, имеющие кудабольше проблем.P.P.S.: ничего извышеописанного не является “новостью” для команды разработчиков MySQL.Эта заметка - лишь попытка осветить некоторые аспекты безопасности иобеспечения корректной работы MySQL-сервера.