转载 2007年10月10日 14:59:00


Top 10 SQL Performance Tips (MySQL优化技巧10)

SQL Performance Tips  From Mysql Wiki.

Interactive session from MySQL Camp I:

Specific Query Performance Tips (see also database design tips for tips on indexes):

  1. Use EXPLAIN to profile the query execution plan
  2. Use Slow Query Log (always have it on!)
  3. Don't use DISTINCT when you have or could use GROUP BY
  4. Insert performance
    1. Batch Insert and REPLACE
    2. Use LOAD DATA instead of Insert
  5. LIMIT m,n may not be as fast as it sounds
  6. Don't use orDER BY RAND() if you have > ~2K records
  7. Use SQL_NO_CACHE when you are Selecting frequently updated data or large sets of data
  8. Avoid wildcards at the start of LIKE queries
  9. Avoid correlated subqueries and in select and where clause (try to avoid in)
  10. No calculated comparisons -- isolate indexed columns
  11. ORDER BY and LIMIT work best with equalities and covered indexes
  12. Separate text/blobs from metadata, don't put text/blobs in results if you don't need them
  13. Derived tables (subqueries in the FROM clause) can be useful for retrieving BLOBs without sorting them. (Self-join can speed up a query if 1st part finds the IDs and uses then to fetch the rest)
  14. Alter TABLE...ORDER BY can take data sorted chronologically and re-order it by a different field -- this can make queries on that field run faster (maybe this goes in indexing?)
  15. Know when to split a complex query and join smaller ones
  16. Delete small amounts at a time if you can
  17. Make similar queries consistent so cache is used
  18. Have good SQL query standards
  19. Don't use deprecated features
  20. Turning or on multiple index fields (<5.0) into UNION may speed things up (with LIMIT), after 5.0 the index_merge should pick stuff up.
  21. Don't use COUNT * on Innodb tables for every search, do it a few times and/or summary tables, or if you need it for the total # of rows, use SQL_CALC_FOUND_ROWS and Select FOUND_ROWS()
  22. Use Insert ... ON DUPLICATE KEY update (Insert IGNORE) to avoid having to Select
  23. use groupwise maximum instead of subqueries

Scaling Performance Tips:

  1. Use benchmarking
  2. isolate workloads don't let administrative work interfere with customer performance. (ie backups)
  3. Debugging sucks, testing rocks!
  4. As your data grows, indexing may change (cardinality and selectivity change). Structuring may want to change. Make your schema as modular as your code. Make your code able to scale. Plan and embrace change, and get developers to do the same.

Network Performance Tips:

  1. Minimize traffic by fetching only what you need.
    1. Paging/chunked data retrieval to limit
    2. Don't use Select *
    3. Be wary of lots of small quick queries if a longer query can be more efficient
  2. Use multi_query if appropriate to reduce round-trips

OS Performance Tips:

  1. Use proper data partitions
    1. For Cluster. Start thinking about Cluster *before* you need them
  2. Keep the database host as clean as possible. Do you really need a windowing system on that server?
  3. Utilize the strengths of the OS
  4. pare down cron scripts
  5. create a test environment
  6. source control schema and config files
  7. for LVM innodb backups, restore to a different instance of MySQL so Innodb can roll forward
  8. partition appropriately
  9. partition your database when you have real data -- do not assume you know your dataset until you have real data

MySQL Server Overall Tips:

  1. innodb_flush_commit=0 can help slave lag
  2. Optimize for data types, use consistent data types. Use PROCEDURE ANALYSE() to help determine the smallest data type for your needs.
  3. use optimistic locking, not pessimistic locking. try to use shared lock, not exclusive lock. share mode vs. FOR Update
  4. if you can, compress text/blobs
  5. compress static data
  6. don't back up static data as often
  7. enable and increase the query and buffer caches if appropriate
  8. config params -- http://docs.cellblue.nl/2007/03/17/easy-mysql-performance-tweaks/ is a good reference
  9. Config variables & tips:
    1. use one of the supplied config files
    2. key_buffer, unix cache (leave some RAM free), per-connection variables, innodb memory variables
    3. be aware of global vs. per-connection variables
    4. check SHOW STATUS and SHOW VARIABLES (GLOBAL|SESSION in 5.0 and up)
    5. be aware of swapping esp. with Linux, "swappiness" (bypass OS filecache for innodb data files, innodb_flush_method=O_DIRECT if possible (this is also OS specific))
    6. defragment tables, rebuild indexes, do table maintenance
    7. If you use innodb_flush_txn_commit=1, use a battery-backed hardware cache write controller
    8. more RAM is good so faster disk speed
    9. use 64-bit architectures
  10. --skip-name-resolve
  11. increase myisam_sort_buffer_size to optimize large inserts (this is a per-connection variable)
  12. look up memory tuning parameter for on-insert caching
  13. increase temp table size in a data warehousing environment (default is 32Mb) so it doesn't write to disk (also constrained by max_heap_table_size, default 16Mb)
  14. Run in SQL_MODE=STRICT to help identify warnings
  15. /tmp dir on battery-backed write cache
  16. consider battery-backed RAM for innodb logfiles
  17. use --safe-updates for client
  18. Redundant data is redundant

Storage Engine Performance Tips:

  1. InnoDB ALWAYS keeps the primary key as part of each index, so do not make the primary key very large
  2. Utilize different storage engines on master/slave ie, if you need fulltext indexing on a table.
  3. BLACKHOLE engine and replication is much faster than FEDERATED tables for things like logs.
  4. Know your storage engines and what performs best for your needs, know that different ones exist.
    1. ie, use MERGE tables ARCHIVE tables for logs
    2. Archive old data -- don't be a pack-rat! 2 common engines for this are ARCHIVE tables and MERGE tables
  5. use row-level instead of table-level locking for OLTP workloads
  6. try out a few schemas and storage engines in your test environment before picking one.

Database Design Performance Tips:

  1. Design sane query schemas. don't be afraid of table joins, often they are faster than denormalization
  2. Don't use boolean flags
  3. Use Indexes
  4. Don't Index Everything
  5. Do not duplicate indexes
  6. Do not use large columns in indexes if the ratio of Selects:Inserts is low.
  7. be careful of redundant columns in an index or across indexes
  8. Use a clever key and orDER BY instead of MAX
  9. Normalize first, and denormalize where appropriate.
  10. Databases are not spreadsheets, even though Access really really looks like one. Then again, Access isn't a real database
  11. use INET_ATON and INET_NTOA for IP addresses, not char or varchar
  12. make it a habit to REVERSE() email addresses, so you can easily search domains (this will help avoid wildcards at the start of LIKE queries if you want to find everyone whose e-mail is in a certain domain)
  13. A NULL data type can take more room to store than NOT NULL
  14. Choose appropriate character sets & collations -- UTF16 will store each character in 2 bytes, whether it needs it or not, latin1 is faster than UTF8.
  15. Use Triggers wisely
  16. use min_rows and max_rows to specify approximate data size so space can be pre-allocated and reference points can be calculated.
  17. Use HASH indexing for indexing across columns with similar data prefixes
  18. Use myisam_pack_keys for int data
  19. be able to change your schema without ruining functionality of your code
  20. segregate tables/databases that benefit from different configuration variables


  1. Hire a MySQL (tm) Certified DBA
  2. Know that there are many consulting companies out there that can help, as well as MySQL's Professional Services.
  3. Read and post to MySQL Planet at http://www.mysqlplanet.org
  4. Attend the yearly MySQL Conference and Expo or other conferences with MySQL tracks (link to the conference here)
  5. Support your local User Group (link to forge page w/user groups here)

Authored by

Jay Pipes Sheeri Kritzer Bill Karwin Ronald ("Jeremy Basher") Bradford Farhan "Frank Mash" Mashraqi Taso Du Val Ron Hu Klinton Lee Rick James Alan Kasindorf Eric Bergen Kaj Arno Joel Seligstein Amy Lee



没索引与有索引的区别优点: 当表中有大量记录时,若要对表进行查询,如果没用建立索引,搜索信息方式是全表搜索,是将所有记录一一取出,和查询条件进行一一对比,然后返回满足条件的记录,这样做会消耗大量数据...
  • u013474436
  • u013474436
  • 2015年11月18日 16:13
  • 6010


Sql语句优化和索引 1.Innerjoin和左连接,右连接,子查询 A.     inner join内连接也叫等值连接是,left/rightjoin是外连接。 SELECT A.id,A....
  • kevinlifeng
  • kevinlifeng
  • 2015年01月28日 17:10
  • 12289

【MySQL】优化 SQL SELECT 语句性能的 6 个简单技巧

  • fu_zk
  • fu_zk
  • 2015年05月04日 16:52
  • 1387


说明:本文中的优化技巧适用于MySQL5.1-5.6版本,且只针对于大部分常见应用场景,是否适用应以实际测试数据为准。 1 优先把列设置为NOT NULL 允许NULL的列不仅占用更多磁盘空间,而且会...
  • autfish
  • autfish
  • 2016年06月13日 23:31
  • 6589

MySQL 性能调优的10个方法

MYSQL 应该是最流行了 WEB 后端数据库。WEB 开发语言最近发展很快,PHP, Ruby, Python, Java 各有特点,虽然 NOSQL 最近越來越多的被提到,但是相信大部分架构师还是...
  • u011225629
  • u011225629
  • 2015年07月27日 22:34
  • 4637


思维导图   点击图片,可查看大图。    介绍   情况:如果你的表结构设计不良或你的索引设计不佳,那么请你优化你的表结构设计和给予合适的索引,这样你的查询性能就能提高几个数量级。——...
  • aya19880214
  • aya19880214
  • 2015年05月20日 15:48
  • 1717

MySQL in查询优化<一>

开发说他写了个SQL特别慢,让看看。 select * from t_channel where id_ in(select distinct cdbh from sjkk_gcjl where jg...
  • gua___gua
  • gua___gua
  • 2015年08月10日 17:57
  • 3914


  • z15818264727
  • z15818264727
  • 2016年08月24日 16:45
  • 5221


原文:7 keys to better MySQL performance 作者:Peter Zaitsev 译者:Peter 译者注: 随着尺寸和负载的增长,MySQL的性能会趋于下降。...
  • dev_csdn
  • dev_csdn
  • 2017年11月02日 14:19
  • 16767


MySQL进行优化, 效果: SQL和索引 > 数据库表结构 > 系统配置 > 硬件 ;但成本从低到高。...
  • sinat_23080035
  • sinat_23080035
  • 2016年10月13日 00:26
  • 3685