MySQL is a powerful open source database. As more and more database-driven applications, it has been promoting the development of MySQL to its limits. Here are 101 tips to tune and optimize MySQL installed. Some are for specific skills . installation environment, but these ideas are generic and I've put them into categories to help you to have more regulation and optimization techniques MySQL.
MySQL server hardware and operating system regulation:
1. have enough physical memory to load the entire file into memory InnoDB - much faster than accessing the hard disk when the memory speed when accessing files 2. Avoid at all costs the use of swap Swap - exchange time is read from the hard disk, it is very slow 3. the battery-powered RAM (Note: RAM i.e. random Access memory) 4. advanced RAID (Note: Redundant arrays of Inexpensive disks, i.e., disk array) - the most. or more preferably from 5 to avoid a RAID5 RAID10 (Note: a storage performance, data security and storage costs both of storage solution) - ensuring database integrity check comes at a price and 6. the operating system separate data partition on just the logical, physical further comprising - read and write performance of the operating system can affect the MySQL database 7. the temporary space and copying the log data into different partitions - when the background database from disk read and write operations affect the performance of the database 8. the more disk space equal faster disk 10. 9. the use of better and faster the SAS (Note:... Serial At tached SCSI, Serial Attached SCSI) instead of SATA (Note:.. SATA, i.e. serial hard drive) 11. The relatively large fast smaller hard drives, battery support 12. In particular in the case of a RAID configuration cache . avoid using the RAID controller software 13. 14. a disk array data partition is considered to use a solid IO card (not the disk drives) -. these cards can be almost any number of data support 2GB / s 15. in the write speed Linux swappiness set value is 0 - no reason in the database server cache files, this is the advantage of a server or desktop 16. If possible, use noatime and nodirtime mount the file system - there is no reason to modify the access database file update time 17. using the XFS file system - a compared ext3 faster, smaller file systems, and there are many logging options, and ext3 has been linked to MySQL with double buffering issues 18. the adjustment XFS file system and log buffer variables. - for the highest performance standards 19. Linux in the system.
MySQL configuration:
25. When writing, to avoid using innodb_flush_method = O_DIRECT 26. avoid the use of double buffering O_DIRECT EXT3 file system, and - you will be written to all of the sequence 27. The dispensing innodb_buffer_pool_size sufficient to load the entire file into memory InnoDB - less read from disk 28. Do not innodb_log_file_size parameter settings too, so you can quickly have more disk space at the same time - lost more logs are usually good, can reduce the time to recover the database after a database crash. 29. Do not mix innodb_thread_concurrency and thread_concurrency parameters - these two values are not compatible with 30. the allocation of a minimum quantity to max_connections parameter - too many connections run out of RAM and lock the MySQL service 31. thread_cache maintained at a relatively higher numbers, about 16 - prevent slow when opening connections 32. the use of skip-name-resolve parameters -.. 33. If you remove the DNS lookup queries are repetitive, and the data does not change often, you can use the query cache. but if your data changes frequently, so use Inquiry cache will make you feel disappointed. 34. temp_table_size increased value to prevent increases max_heap_table_size written to the disk 35. The value written to the disk to prevent too high 36. Do not set sort_buffer_size value, otherwise your memory will soon run out of 37. key_buffer to determine the size according to key_read_requests and key_reads value, key_read_requests key_reads value should be higher than under normal circumstances, otherwise you can not be an efficient use key_buffer 38. innodb_flush_log_at_trx_commit set to 0 will improve performance, but if you want to Keep the default value (1), then you have to ensure data integrity, and you must also ensure that replication does not lag. 39.
MySQL optimization mode:
40. Keep your old database manageability 41. Data Archiving - Remove the extra line returns or search query your data plus 42. The index 43. Do not overuse the index, compared with 44 queries.... the compression of text and BLOB data types -.. to save space and reduce the number of disk reads 45. UTF 8 and UTF16 are lower than latin1 efficiency 46. use sparingly to keep the flip-flop 47. the redundant data to a minimum - no unnecessary duplication of data. 48. the link table, rather than extending the line 49. Note that the data type in your real data, a minimum of 50. If other data is often used to query using as much as possible, and BLOB / TEXT data is not, put the BLOB / TEXT data separated out from other data. 51. the inspection and regular optimization table 52. table InnoDB optimization often rewritten 53. sometimes, when added to delete the index column, then adding back to the index, which would quickly 54. for different needs, different storage engines use 55. using the archive storage engine tables or audit log table -... it is more efficient to write session data stored in the buffer 56. (Memcache) instead of MySQL - the cache is automatically allowed to automatically fill in values, and prevent you from creating hard to read and write to MySQL spatial and temporal data using VARCHAR variable-length strings 57. The storage time instead of CHAR -. Saving space, because CHAR fixed-length and fixed length VARCHAR (UTF8 not affected by this) 58. the gradual change mode - a small change can have a huge impact 59. the tested all modes in the development environment. reflect changes in production. 60. Do not change the value of your configuration file, it can have disastrous effects. 61. sometimes, the MySQL configs less is more. 62. the use of a common MySQL configuration when in doubt file
query optimization:
63. Use slow query log to find the slow query execution plan to judge 64. The use of a query whether the normal operation of 65. Always test your queries to see if they are running in the best condition -... Over time the performance will always change 66 avoid using count (*) over the entire table, it may lock the entire table. 67. the follow-up to the inquiry consistent with similar queries can use the query cache. 68. using the GROUP BY DISTINCT instead in appropriate cases. 69. the use WHERE, GROUP BY and ORDER BY clause indexed columns. 70. the index kept simple, is not included in the index more than one column with 71. sometimes MySQL will use the wrong index, in this case use uSE iNDEX. 72. examined using sQL_MODE = STRICT problem. 73. for recording the number of index fields less than 5, in a LIMIT UNION when not is OR. 74. in order to avoid pre-update SELECT, using INSERT oN DUPLICATE KEY or INSERT IGNORE, do not use UPDATE to achieve. 75. Do not use MAX, using the index field and ORDER bY clauses. 76. avoid using ORDER bY RAND (). 77. LIMIT M, N can actually slow down a query Under some circumstances, it is used sparingly. UNION 78. Instead of using a subquery in the WHERE clause. 79. UPDATES (updated) using SHARE MODE (shared mode) to prevent an exclusive lock. 80. restart MySQL remember to warm your database to make sure your data is in memory and fast query speed. 81. the use DROP tABLE, CREATE tABLE dELETE fROM deletes all data from a table. 82. minimize data in the query data you need, use * consume a lot of time. 83. consider a persistent connection, rather than multiple connections, to reduce overhead. 84. the base query, including the use of load on the server, sometimes a simple query can affect other queries. 85. when the load increases on your server, use SHOW PROCESSLIST to see slow and problematic query. 86.
: MySQL backup process
stops 88. 87. During performing backup from the backup copy on the secondary server replication, to avoid inconsistencies in the data dependency and foreign key constraints completely stop 89. MySQL, 90 from the database file backup... If you are using MySQL dump backup, please back up the binary log files - make sure to copy without interruption 91. LVM snapshots do not trust - which is likely to produce inconsistent data, the future will bring you trouble 92. In order to more easily conduct a single table recovery, export data to the table as a unit -... If the data is isolated from the other table 93. when using mysqldump use -opt 94. before backup optimization checks and table 95. for faster import, import when temporarily disable foreign key constraints. 96. for faster import, when introduced into the unique temporarily disable detection. 97. the calculation database size, and the index of the table after each backup, in order to be more growth monitoring data size. 98. copy the script by scheduling automatic monitoring of errors and delays instance regularly perform backups 100. 99. regularly test your backup 101:... execute MySQL monitoring: Monitis Unveils The World's First Free
Reproduced in: https: //my.oschina.net/766/blog/211554