Григорий Перетяка

Отдельно:
sudo yum install php-mysql

При удалении вам должен был быть показан список зависимостей, которые так же удаляются.

Сортировка — тяжелая операция, что вас удивляет? Используйте inner join, пробуйте джойнить уже отфильтрованные данные, как-то так:

SELECT SQL_NO_CACHE news.*, news_category.name AS category FROM news
INNER JOIN news_category ON (news.news_category_id = news_category.id AND news_category.id != 114 AND news_category.active_status = 1)
WHERE AND create_date < CURRENT_DATE AND FIND_IN_SET(50, news.region_ids) AND news.active_status = 1
ORDER BY id DESC LIMIT 3

Ну и индексы не помешают.

Сделайте несколько сайтов на разных популярных CMS: Joomla, MODX, Drupal,… Напишите для них по модулю/компоненту.

Что бы не делать лишнюю работу — можно взять проекты на фрилансе плюс будет хотя бы символическая оплата.

Что касается работы над CMS, я бы посоветовал взять за основу какой-нибудь фреймворк. Сейчас, я бы взял Zend, так как он написан академически правильно, но в то же время он довольно сложный для восприятия новичкам. Из попроще, вроде бы, Yii сейчас в моде.

А дальше, навесьте на фрейморк все лучше, что вы вы видели в каждой CMS или даже придумайте новое решение конкретной задачи. Как-то так делал я.

Вообще, написание CMS — это для «тру» велосипедистов. Нужно смотреть правде в глаза: вряд ли у вас получится что-нибудь ценное, но это поможет вам разобраться в тонкостях проектирования модульной системы, предметной области CMS, надеюсь, ООП, паттерне MVC и шаблонизаторах, а также вы получите бесценный опыт разработки огромного и сложного проекта.

В общем, лично мой уровень после написания такого велосипеда за год взлетел с что-то могу написать с нуля, до я могу все и спокойно без опыта работы даже с Зендом и чтения мануалов пишу на Magenta, который вот совсем недавно казался китайской грамотой.

Тут есть мнения с которыми я не совсем согласен. Давайте, разберем что такое индекс в упрощенной форме.

Если индекс на поле не установлен, то он проходит по всем записям и сравнивает, если флаг = 1, то выбрать запись. При миллионе записей будет миллион таких сравнений.

Если вы поставите индекс, то он сократит список до уникальных значений и он будет следующего вида:
0 — строки, где запись равна 0
1 — строки, где запись равна 1

То есть, сравнений будет всего 2.

Если вы объедините поля, то в индексе получится 999 900 уникальных временных значений и одно — 0, соответствующие 100 записям то есть будет 999 901 сравнение.

(если поле вообще уникальное, то выигрыш в том, что он остановит поиск после первого найденного элемента)

(это далеко не все, в чем заключается работа индексов, к тому же есть разные типы, нюансы)

Насколько вообще существенно сравнение интежеров даже помноженное на миллион я не берусь судить, как и об увеличении обращений к жесткому диску. Но это будет однозначно дольше, вопрос только насколько, тут уже надо тестировать.

Другая ситуация с NULL. IS NULL — всегда будет работать без сравнения вообще. Тут я бы так и сделал.

И вообще, принято обозначать колонки так, а то у вас ничего не понятно:

Таблица articles
id
title

Таблица article_tags
id
article_id
value

SELECT DISTINCTROW
articles.id,
articles.title,
tags1.id as article_id (если нужно будет выгребать одноименные поля из разных таблиц)

FROM articles
LEFT JOIN article_tags AS tags1 ON articles.id = tags1.article_id
LEFT JOIN article_tags AS tags2 ON articles.id = tags2.article_id

WHERE articles.id = 262
AND tags1.value = 4447
AND tags2.value = 4448

Наверное, так проще всего два раза джойнить таблицу pt.

А что значит не потянет?

Размер таблицы в MS SQL ограничен только размером диска.

Другой вопрос — обработка данных, будет медленно, возможно будут ошибки, но это проблема настроек или несоответствие запрашиваемых объемов данных размеру оперативной памяти. Первая проблема с помощью гугла или довольно дешевого специалиста легко решается, а вторую все равно придется исправлять в клиенте независимо от базы.

Если key-value вас устраивает, то такие движки конечно же будут работать на порядок быстрее, есть куча популярных.

Тут я должен был сказать, что если другая модель не SQL более оптимально описывает ваши данные, то лучше использовать ее. Но такие базы, пока, не сравнятся по популярности с реляционными и нет исчерпывающей информации по всем возможным проблемам. Кроме того, на мой взгляд, производительность там также не очень откатана и вот там вполне может «не потянуть» внезапно и по непонятным причинам. В общем я бы рекомендовал такой вариант только если у вас какой-то совсем запущенный случай, который никак приемлемо не решить с помощью реляционной базы. А просто так на таких объемах я бы не экспериментировал.

И вообще все эти тесты — фигня. Единственный нормальный тест — это создать вашу таблицу на двух движках, заполнить демо-данными и протестировать с реальными запросами и под нагрузкой близкой к ожидаемой. Хотя и это не дает полной картины, есть еще такие нюансы как: надежность, горячие бэкапы или даже зеркало, если потеря даже последних данных критична, масштабируемость, итд.

Да и заказчика понимаю, поставите вы ему сейчас что-то модное и NOSQL, пусть даже производительность в несколько раз лучше (хотя тут тоже вопросы), а ему потом в случае чего придется срочно искать специалистов на эту базу, которые еще и возьмут втридорога.

Встроенного в MySQL инструмента нет.

В простейшем случае достаточно обрезать окончания в словах запроса. Если нужно что-то покруче — более сложные варианты вплоть до использования словарей. Какой язык вы используете? Возможно, уже написаны готовые решения.

Если допустимо использование сторонних модулей и работа по настройке индексирования оправдана, то лучше перейти на Sphinx, есть поддержка русской морфологии, в любом случае скорость поиска выше, и вообще специализированный современный инструмент, в отличии от MyISAM.

Мое, не авторитетное, мнение:

Хранимые процедуры — это перенос части логики в БД. В некоторых случая может быть какой-то рост производительности, но в среднем можно сказать, что разница несущественная. Другой вопрос, что эту логику будет выполнять сервер db, а не сервер приложения, иногда это важно.

Кстати, заметил у вас неоднозначную фразу, потому, на всякий случай: мерить нагрузку количеством запросов не получится, потому, что есть запросы на микросекунды, а есть сложные, которые могут несколько дней выполнятся, не говоря уже о том, что для получения одних и тех же данных несколько запросов могут быть более эффективными, чем один.

Так, что хранимые процедуры, в основном, ради удобства. В сайтах и веб-приложениях я пробовал делать все на процедурах, но в итоге практически полностью от них отказался, после нескольких доработок все уже не так красиво становится. Сейчас использую только в редких, специфических, случаях и, в основном, в связке с триггерами.

Нагуглил вот это: webi.ru/webi_articles/8_14_f.html

Похоже, это то, что вы искали. Но, мне кажется, это костыль, вряд ли будет всегда или хотя бы иногда работать быстрее.

Сразу предупреждаю, я не гуру по базам и вообще такие вопросы лучше задавать на профильных ресурсах, например, на sql.ru.

Есть вложенные запросы, погуглите. Но, по-моему, особого прироста это не даст, они нужны просто для того, что бы перенести логику из приложения в запрос. То есть, по производительности, равносильно тому, что вы загрузите данные из первой таблицы, а затем циклом из второй.

В общем, если бы производительность была очень важна, я бы делал так:
1) если предполагаемый массив данных небольшой, то выбирал бы одним запросом
2) если большой, то двумя, второй по списку id, так как может кушать много памяти

Обработал бы полученные данные и привел бы к требуемому виду уже непосредственно в приложении.

Сталкивался с такой проблемой. В моем случае дело было в индексах. Можно попробовать DISABLE KEYS. У меня эта функция почему-то не все индексы отключала.

Если не получится, то можно просто на время снести все ключи, индексы, итп, удалить записи, а потом снова поставить. Но на это время нужно предотвратить запись данных. Я делал так, но, скорее всего, есть более красивый способ.

Есть «триггеры», возможно это вам подойдет. Погуглите «триггеры MySQL», информации по этой теме много даже на русском.

У меня есть таблица на 50 миллионов строк, правда, ой мучаюсь я с ней.

А вообще, очень много крупных проектов работает на MySQL, думаю, у них на порядок больше, так, что обозримого лимита нет, все зависит от конфигурации ПО и железа.

Такую тему уже поднимали. Ваша первая модель похожа на ТИП 4.

Зачем поле param1_is_changed? Нужно определять какое именно поле изменилось, они меняются не группой?

Логики во втором методе, пока, не вижу.

Думаю, можно будет спроектировать так, что бы при выборке разницы а производительности не было.