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的值,用基于内存的临时表代替基于磁盘的