1.在linux系统中使用which mysqld确定msyql的配置文件所在
2.配置设置都是小写的，使用下划线或破折号分割单词
3.在32位的linux操作系统上，单个进程使用的内存是2.5G-2.7G，系统函数库不能一次分配2G大小的内存，所以mysql的任何配置都应该小于2G
4.最重要的缓存:操作系统为myisam的数据提供的缓存、myisam的缓存、InnoDB缓存池、查询缓存
5、MyISAM键缓存，只缓存了索引，没有数据
key_buffer_size,它的值应该占到保留内存的25%-50%，改变量的最大上限是4GB，即使没有使用myisam，也要为key_buffer_size设置一个值，如32M
myisam_block_size控制了键缓存块的大小，默认是4k
6、thread_cache_size 线程缓存，除非服务器有很多连接，否则就没有必要改变该值
7、给InnoDB的缓存池分配比较大的内存，在专用服务器上应该分配80%的物理内存，innodb_buffer_pool_size
8、在mysql5.1中，表缓存被分为了两部分，打开表和表的定义(table_open_cache和table_definition_cache)，通常可以把table_definition_cache设置的足够高，以缓存所有表的定义。如果使用show status like '%open%'命令查看Opened_tables值很大或上升的很快，那就应该加大table_open_cache.如果mysql提示不能打开更多文件，那就应该提高open_files_limit 的值。
9、myisam：批处理通常性能会更好。delay_key_write变量来延迟索引的写入。myisam_recover_options决定了在打开MyISAM表的时候以何种方式恢复。myisam_use_mmap内存映射，开启将可以直接通过系统页面缓存访问.myd。
10.当一个查询中任何列超过了max_length_for_sort_data规定的大小，将使用双路排序。诸如text、blob列可以使用substring截取部分。
11、全局变量解释：
show global status;
+-----------------------------------+----------+
| Variable_name | Value |
+-----------------------------------+----------+
| Aborted_clients | 0 |
如果这个变量随时间增加，就要确定连接是否关闭了
| Aborted_connects | 0 |
这个值应该接近于0
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 0 |
上面两个值之间的比率如果很大的话，就应该增加binlog_cache_size的值
| Bytes_received | 666 |
| Bytes_sent | 223011 |
这两个值如果很大的话，要确定是否提取了不需要的数据
| Com_* | 0 |
注意不要出现不常用的值
| Compression | OFF |
| Connections | 4 |
该值如果过大，就要检查连接数
| Created_tmp_disk_tables | 1 |
如果该值过大，有两种情形，blob或text列创建了临时表
tmp_table_size和max_heap_table_size可能不够大
| Created_tmp_files | 5 |
| Created_tmp_tables | 7 |
该值如果较高，优化查询
| Delayed_errors | 0 |
| Delayed_insert_threads | 0 |
| Delayed_writes | 0 |
| Flush_commands | 1 |
| Handler_commit | 0 |
| Handler_delete | 0 |
| Handler_discover | 0 |
| Handler_prepare | 0 |
| Handler_read_first | 3 |
| Handler_read_key | 0 |
| Handler_read_next | 0 |
| Handler_read_prev | 0 |
| Handler_read_rnd | 0 |
| Handler_read_rnd_next | 1369 |
Handler_read_rnd_next/Handler_read_rnd显示了全表扫描的大致
平均值，如果该值较高，那就应该优化架构和索引
| Key_blocks_not_flushed | 0 |
| Key_blocks_unused | 75897 |
| Key_blocks_used | 0 |
Key_blocks_used*Key_cache_blocks_size远远小于key_buffer_size
则表示key_buffer_size过大，内存被浪费了
| Key_read_requests | 0 |
| Key_reads | 0 |
注意观察美妙发生的最大读取数
| Key_write_requests | 0 |
| Key_writes | 0 |
| Last_query_cost | 0.000000 |
| Max_used_connections | 3 |
如果该值和max_connections相同，那么是max_connections
设置的可能过小。但该值不要轻易增大。
| Not_flushed_delayed_rows | 0 |
| Open_files | 20 |
注意他不要和open_file_limit接近，如果接近了
open_file_limit应该增大。
| Open_streams | 0 |
| Open_table_definitions | 16 |
| Open_tables | 9 |
| Opened_tables | 16 |
应该将该值和table_cache进行对比，如果每秒有太多
opened_tables,那么说明table_cache还不够大。
| Opened_files | 68 |
| Opened_table_definitions | 16 |
| Prepared_stmt_count | 0 |
| Qcache_* | 0 |
| Queries | 14 |
| Questions | 14 |
| Rpl_status | NULL |
| Select_full_join | 0 |
全联接是无索引联接，真正的性能杀手，最好能避免全连接。
| Select_full_range_join | 0 |
如果该值过高，表明使用了范围查询联接表。可以优化。
| Select_range | 0 |
| Select_range_check | 0 |
表示了在联接时，对每一行数据重新检索索引的查询计划数量。这个
性能开销很大。
| Select_scan | 8 |
| Slave_open_temp_tables | 0 |
| Slave_retried_transactions | 0 |
| Slave_running | OFF |
| Slow_launch_threads | 0 |
该变量较大说明了某些因素正在延迟联接的新线程。通常表示系统过载。
| Slow_queries | 0 |
| Sort_merge_passes | 0 |
该变量较大，应该增加sort_buffer_size.最好的办法是优化查询。
| Sort_range | 0 |
| Sort_rows | 0 |
| Sort_scan | 0 |
| Ssl_accept_renegotiates | 0 |
| Ssl_accepts | 0 |
| Ssl_callback_cache_hits | 0 |
| Ssl_cipher | |
| Ssl_cipher_list | |
| Ssl_client_connects | 0 |
| Ssl_connect_renegotiates | 0 |
| Ssl_ctx_verify_depth | 0 |
| Ssl_ctx_verify_mode | 0 |
| Ssl_default_timeout | 0 |
| Ssl_finished_accepts | 0 |
| Ssl_finished_connects | 0 |
| Ssl_session_cache_hits | 0 |
| Ssl_session_cache_misses | 0 |
| Ssl_session_cache_mode | NONE |
| Ssl_session_cache_overflows | 0 |
| Ssl_session_cache_size | 0 |
| Ssl_session_cache_timeouts | 0 |
| Ssl_sessions_reused | 0 |
| Ssl_used_session_cache_entries | 0 |
| Ssl_verify_depth | 0 |
| Ssl_verify_mode | 0 |
| Ssl_version | |
| Table_locks_immediate | 19 |
| Table_locks_waited | 0 |
有多少表被锁住，并导致了服务器级的锁等待。如果该值较高
说明有严重的并发瓶颈。考虑使用InnoDB，手动对大表进行分区
，优化查询，启用并发插入或者对锁定设置进行优化。
| Tc_log_max_pages_used | 0 |
| Tc_log_page_size | 0 |
| Tc_log_page_waits | 0 |
| Threads_cached | 0 |
| Threads_connected | 3 |
| Threads_created | 3 |
该变量较大或正在增加，就应该考虑增加thread_cache_size的
可以通过检查thread_cache知道多少线程在缓存中。
| Threads_running | 1 |
| Uptime | 1007 |
| Uptime_since_flush_status | 1007 |
+-----------------------------------+----------+
aborted_clients 客户端非法中断连接次数
aborted_connects 连接mysql失败次数
com_xxx xxx命令执行次数,有很多条
connections 连接mysql的数量
Created_tmp_disk_tables 在磁盘上创建的临时表
Created_tmp_tables 在内存里创建的临时表
Created_tmp_files 临时文件数
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同时使用的连接数
Open_tables 开放的表
Open_files 开放的文件
Opened_tables 打开的表
Questions 提交到server的查询数
Sort_merge_passes 如果这个值很大,应该增加my.cnf中的sort_buffer值
Uptime 服务器已经工作的秒数
提升性能的建议:
1.如果opened_tables太大,应该把my.cnf中的table_cache变大
2.如果Key_reads太大,则应该把my.cnf中key_buffer_size变大.可以用Key_reads/Key_read_requests计算出cache失败率
3.如果Handler_read_rnd太大,则你写的SQL语句里很多查询都是要扫描整个表,而没有发挥索引的键的作用
4.如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用Threads_created/Connections计算cache命中率
5.如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基于内存的临时表代替基于磁盘的