Рассказываю из личного опыта из того же SoooFast\’а и прочих скриптов буксов.Рассказываю из личного опыта из того же SoooFast\’а и прочих скриптов буксов.
1. Проектируйте сначала свою базу данных, а потом уже делайте.
2. Старайтесь не использовать varchar, используйте ENUM, который столбцы типа ENUM работают быстрее и компактнее.
3. Так-же заметил, все хранят IP в varchar (15), даже не думая, что будут хранить в этом поле целочисленное значение. Если использовать INT, то размер поля сократится до 4 байт, и оно будет иметь фиксированную длину.
Нужно использовать тип UNSIGNED INT, так как IP адрес задействует все 32 бита беззнакового целого.
В запросах можно использовать функцию INET_ATON() для конвертации IP адреса в целое, и INET_NTOA() для обратного процесса. Также есть схожие функции PHP: ip2long() и long2ip().
4. Если выполняете большие запросы delete или insert, то разделяйте их, допустим, паузой: usleep(50000);
5. Если у вас в БД храниться дата, то не храните её в varchar (10) и т.д., а храните в DATE.
6. Храните свои пароли всегда в MD5. Это признак хорошего тона, защиты и экономия место в базе, т.к. начиная с MySQL 5.5.15 ввели специальный тип MD5. Т.е. теперь хеш пароли не надо хранить в varchar (32), а в md5, что является огромным плюсом.
7. Не используйте драйвер для работы с базой MySQL, т.к. он устарел его уже пора пометить как depricated, что и будет сделано начиная с php 5.5, а с выходом php6 прекратят его поддержку, и с выходом MySQL 6, как обещают нам разработчики, к маю месяцу с сокета MySQL демона будет снят MySQL и останется MySQLi. Используйте либо mysqli или pdo.
8. Не используйте mysqli_fetch_array, используйте всегда mysqli_fetch_assoc, он быстрее, так же mysqli_fetch_array давно пора пометить как deprecated.
9. Поговорим о типах таблиц.
Старайтесь уже переходить с MYISAM, которого не будет в MYSQL 6, он будет заменен полностью на Falcon и Aria.
Myisam — это самое слабое место MYSQL, при высоких нагрузках большим таблицам типа MYISAM свойственно крошиться и довольно трудоёмко и долгоёмко бывает восстановление таблицы, чего нет в ARIA, которые более устойчивы к нагрузкам и быстро и легко-восстанавливаемые.
P.S. Myisam быстрее на простых выборках. Если есть нагружающие выборки по большим текстовым полям, то fulltext индекс myisam будет много быстрее, чем like по innodb. Это всё довольно общие характеристики и в конкретных случая могут изменяться, но в целом так и есть: Myisam быстрее, чем innodb.
А насчет ARIA VS MYISAM — производительность абсолютно одинаковая.
10. Старайтесь динамические таблицы напрямую держать в оперативной памяти (из которых не жалко потерять инфу), в типе таблиц MEMORY. В суфасте, например, таблицу user_online можно спокойно держать в типе MEMORY, а не в Myisam, что будет давать запросы не к базе данных, а напрямую к оперативной памяти (и не надо кешировать, всё будет в реальном времени).
11. Таблицы больших объёмов я рекомендую держать в INNODB, но при этом должна быть включена директива big_table, в суфасте таблицу tb_ads я держу в innodb и не смотря на её огромные объёмы и кучу к ней запросов, она не разу не крашнулась и работает как часы.
12. Старайтесь всегда использовать id.
13. Не забывайте расставлять индексы и уникальные значения.
14. Старайтесь держать всё тютя в тютю если максимальная длинная кошелька 12 символов, то не надо его хранить в varchar (255) достаточно будет varchar (12).
15. Так же все используют для того же рандомного вывода баннеров ORDER BY RAND() даже не подозревая, что RAND(), занимающая время процессора для каждой отдельной строки в таблице перед тем, как отсортировать ее и выдать вам только одну строку.
Вот так будет лучше:
$d = mysqli_fetch_row($r);
$rand = mt_rand(0,$d[0] — 1);
$r = $mysqli->query("SELECT username FROM banner LIMIT $rand, 1");
16. Не создавайте лишних запросов не забывайте про JOIN и UNION.
17. Вам не подходит JOIN и UNION и вам кажется, что 2 запроса никак не сделать в 1? Не беда, вы, наверное, забыли про MYSQL триггеры.
18. Начиная с MySQL 5.1 запросы можно кешировать со стороны MySQL.
Т.е. запросы, которые выполнялись к базе, они больше не выполняются, а просто отдаётся из оперативной памяти (спасибо разработчикам MySQL за внедрённую фичу). Это делается директивой: query_cache_size=32M — где 32М кол-во мегабайт ОЗУ, которое вы выделил для кеширования запросов MySQL, прописывается в конфиге мускула my.cnf в секции [mysqld]
19. Ну и напоследок, не используйте MySQL напрямую, старайтесь всё кешировать, это может быть как собственный кеш (кешировать результат запросов в файл и отдавать веб сервером), так и более мощные вещи, такие как memcache(d) или Redis.
Автор публикации
Отправить комментарий
Вы должны быть зарегистрированы чтобы оставить комментарий.
Вы должны быть зарегистрированы чтобы оставить комментарий.