实践中如何优化MySQL
他们四条从效果上第一条影响最大，后面越来越小。具体根据实际情况

① SQL语句及索引的优化，不使用*

② 数据库表结构的优化 合理的设计库表结构，不要堆在一起

③ 系统配置的优化 例如内核调优及系统优化

④ 硬件的优化 升级高配服务器

MySQL优化
1.? 避免使用 select *?

2.? ?建立高性能的索引?? 索引不是随便加的也不是索引越多越好,更不是所有索引对查询都有效

3.? ?建数据库表时,给字段设置固定合适的大小.? ? 字段不能设置的太大,设置太大就造成浪费,会使查询速度变慢

5.? ?要尽量使用not null? ?
?
6.? ?如果你有一个字段，比如“性别”，“国家”，“民族”, “省份”，“状态”或“部门”，这些字段的取值是有限而且固定的，那么，应该使用 ENUM 而不是 VARCHAR。??使用合理的数据类型

?因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

7.? 垂直分割? ??将常用和有关系的字段放在相同的表中，把一张表的数据分成几张表? ??这样可以降低表的复杂度和字段的数目，从而达到优化的目的

8.? 优化where查询

? ? ? ? ①. 避免在where子句中对字段进行表达式操作

? ? ? ? ? ? ? ? ? ?比如：?select 列 from 表 where age*2=36;? ?建议改成??select 列 from 表 where age=36/2;

? ? ? ? ②.?应尽量避免在 where 子句中使用?!=?操作符，否则将引擎放弃使用索引而进行全表扫描。

.? ?不建议使用%前缀模糊查询,这种查询会导致索引失效而进行全表扫描

? ? ?例如LIKE “%name”或者LIKE “%name%这两种都是不建议的.但是可以使用LIKE “name%”。

? ? ?对于LIKE “%name%,可以使用全文索引的形式

?9.? 要慎用in和 not in?

? ? ? ? ? ? ? ? 例如：select id from t where num in(1,2,3)? ?建议改成 select id from t where num between 1 and 3

? ? ? ? ? ? ? ? ?对于连续的数值，能用 between 就不要用 in 了

优化的范围有什么？
1 主机架构稳定性
2 I/O 规划及配置
3 swap 交换分区
4 OS 内核参数和网络问题

应用层面：
1 应用程序稳定性
2 SQL语句性能
3 访问资源

数据库优化方面
1 内存
2 数据库结构（物理 逻辑）
3 实例配置

优化维度

优化成本：
硬件>系统配置>数据库表结构>SQL及索引

优化效果
硬件< 系统配置< 数据库表结构< SQL及索引

应急调优思路

业务办理突然卡顿，无法进行整处理，需要立马解决：
show processlist；
如果有 SUPER 权限，则可以看到全部的线程

id列:一个标识，你要kill 一个语句的时候很有用。

user列: 显示当前用户，如果不是root，这个命令就只显示你权限范围内的sql语句。

host列:显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户。

db列:显示这个进程目前连接的是哪个数据库。

command列:显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）。

mysql> show status like '%lock%';

如当Table_locks_waited与Table_locks_immediate的比值较大，则说明我们的表锁造成的阻塞比较严重，可能需要调整语句，或者更改存储引擎，亦或者需要调整业务逻辑。当然，具体改善方式必须根据实际场景来判断。而Innodb_row_lock_waits较大，则说明Innodb的行锁也比较严重，且影响了其他线程的正常处理。同样需要查找出原因并解决。造成Innodb行锁严重的原因可能是Query语句所利用的索引不够合理（Innodb行锁是基于索引来锁定的），造成间隙锁过大。也可能是系统本身处理能力有限，则需要从其他方面来考虑解决。

系统层面
CPU 内存 内核等 关闭没用的服务

数据库参数优化
vi /etc/my.cnf
table_cache = 64
sort_buffer_size = 8M
join_buffer_size = 4M
thread_cache_size = 300
thread_concurrency = 8
tmp_table_size = 246M

thread_concurrency # 并发线程数量个数
sort_buffer_size # 排序缓存
read_buffer_size # 顺序读取缓存
read_rnd_buffer_size # 随机读取缓存
key_buffer_size # 索引缓存
thread_cache_size # (1G—>8, 2G—>16, 3G—>32, >3G—>64)

连接层优化：

max_connections # 最大连接数，看交易笔数设置
max_connect_errors # 最大错误连接数，能大则大
connect_timeout # 连接超时
max_user_connections # 最大用户连接数
skip-name-resolve # 跳过域名解析
wait_timeout # 等待超时
back_log # 可以在堆栈中的连接数量
=====================================================
show global status like 'Thread%';

发现 threads_created 的值过大，表明MySQL服务器一直在创建线程
查看当前值

show variables like 'thread_cache_size';
此参数需要调高
打开表数量
查看打开表的情况

show global status like 'open%tables%';
发现 opened_tables 数量过大，说明 table_cache 的值可能太小。
查看当前值

show variables like 'table_cache';
此参数需要调高
最大连接数
查看当前允许的最大连接数

show variables like 'max_connections';
查看服务器连接数的峰值

====================================================
存储+
引擎基本优化： 等还有好多，参数自行查阅即可
default-storage-engine
innodb_buffer_pool_size # 没有固定大小，50%测试值，看看情况再微调。但是尽量设置不要超过物理内存70%
innodb_file_per_table=(1,0)
innodb_flush_log_at_trx_commit=(0,1,2) # 1是最安全的，0是性能最高，2折中
binlog_sync
Innodb_flush_method=(O_DIRECT, fdatasync)
innodb_log_buffer_size # 100M以下
innodb_log_file_size # 100M 以下
innodb_log_files_in_group # 5个成员以下,一般2-3个够用（iblogfile0-N）
innodb_max_dirty_pages_pct # 达到百分之75的时候刷写 内存脏页到磁盘。
log_bin
max_binlog_cache_size # 可以不设置
max_binlog_size # 可以不设置
innodb_additional_mem_pool_size #小于2G内存的机器，推荐值是20M。32G内存以上100M