Mysql之深刻浅出

##<center/>Mysql相关知识

一.基本架构

1.服务层:处理客服端和服务端链接以及安全验证。
2.核心层：查询分析，优化，缓存，内置函数/内建视图，存储过程/触发器。
3.存储引擎：数据的存取。

.

二.选择版本

MariaDB 彻底兼容Mysql XtraDB引擎 代替mysql的InnoDB引擎。
企业版：收费
社区版：开源，用的人比较多。
Percona Server:新特性多
MariaDB:国内用的很少。

三.配置文件详解（高性能Mysql）

/etc/my.cnf
1.max_connections.Mysql所容许的最大会话数Too many connections.
2.max_errors（50）最大错误容许数 FLUSH HOSTS 重启服务。
3.key_buffer_size 关联词缓冲区大小，缓存MyISAM索引块，
  索引处理速度 读取索引的速度
4.max_allowed_packet  设置最大包。限制server接受数据块大    
小，执行超长SQL，信息包过大，关闭链接，丢失与Mysql服务器链接的报错。
5.thread_cache_size 服务器线程缓存。
6.thread_concurrency  值为CUP核数*2，设错时，
  Mysql不能很好的利用多核处理器性能。    
7.sort_buffer_size  不是越大越好，1000个链接话，
  分配每一个1MB，就须要 1000*1M = 1GB。
8.join_buffer_size join表使用的缓存的大小
9.query_cache_size 查询缓存大小，查询结果缓存。缓存期间表
  必须没有更改，不然缓存失效，多写操做数据库，设置打了影响
  写入效率。
10.read_buffer_size  在这个MyISAM下 全表扫描的缓冲大小，
	并且查询时没法添加索引全表扫描，增大它可使得它优化。
11.read_rnd_buufer_size  从排序好的数据中读取行时，
   行数据从缓冲区读取能够提高Order by的性能
   注意：mysql会为每一个客户端申请这个缓冲区，并发过大，
	    设置过大影响内存开销大。
12.myisam_sort_buffer_size:MyISAM表发生变化时，从新排序时
   所须要的缓存大小。
13.innodb_buffer_pool_size: innoDB 使用的缓存，用于保存索引
   原始数据的缓存，能够有效减小读取数据所须要的磁盘I/O。
14.innodb_log_file_size:数据日志文件大小，大的值能够提升性      
   能但增长了恢复故障数据库的时间。
15.innodb_log_buffer_size:日志文件的缓存，增大该值能够提升      
   性能，但增大了突然宕机损失数据的风险。
16.innodb_flush_log_at_trx_commit:执行事务的时候，会往
   innodb存储引擎的日志缓存中插入事务日志，写数据前先写日志
   预写日志方式，设置为0时，每秒日志缓存写入文件，文件实时写入磁盘。
   设置为1时，缓存实时写入文件，文件实时写入磁盘，设置为2时
   缓存实时写入文件，每秒日志文件实时写入磁盘。
17.innodb_lock_wait_timeout：被回滚前，一个innodb事务应该
   等待一个锁被批准多久，innodb没法检测死锁发生，这个值有用。

四.软件优化

1.选择合适的引擎
  MyISAM  索引顺序访问方法  支持全文索引，非事务安全，不支持外键，表级锁。
  包含三个文件FRM文件存放表结构，MYD文件存放数据，MYI存放索引。
  InnoDB 事务性存储引擎  行锁（不必定）
 （update table set age = 3where name like "%jam%"会锁表 ，没法知道更新的范围）
  InnoDB是有回滚的，以及崩溃恢复还有ACID事务控制。表和索引放在一个表空间里，表空间会有
  多个文件。
2.正确使用索引
	a.给合适的列创建索引， where子句，链接子句，而不是select选择列表创建索引
	b.索引值应该不相同，惟一值  索引效果最好 有大量重复效果不好。
	c.使用短索引，指定前缀长度，  char(50)  前20 30值惟一 较小的索引，索引缓存必定
      存的索引多，消耗磁盘IO更小，能提升查找速度。
    d.最左前缀 n列索引  最左列值匹配。
    e.like查询，索引失效，尽可能少用like 对于百万，千万用like Sphinx 开源方案结合Mysql.
	f.不能滥用索引
		1）索引占用空间
		2）更新数据 索引必须更新 尽可能不要在长期不用的字段上创建索引。
		3）SQL执行一个查询语句 增长查询优化的时间。
3.避免使用select*
	1.返回结果多，下降查询速度。
	2.过多的返回结果，增大服务器返回给APP端的数据传输量。网络传输速度慢，弱网络环境下
      容易形成请求失效。
4.字段尽可能设置为NOT NULL。
	""和NULL
	｛"name":"myf"｝{"name":""} {"hobby":空array}  null占空间
	 判断""仍是NULL java和OC强制型  APP闪退。

五.硬件优化

1.增长物理内存
  Linux内核，内存开缓存，存放数据。
  -写文件， 文件延迟写入机制，先把文件放到缓存达到必定程度写入硬盘
  -读文件，读文件到缓存，下次须要相同文件从缓存中取，没有从硬盘取。
2.增长应用缓存
	a.本地缓存
	  数据放到服务器内存文件中
	b.分布式缓存
	  Redis Memcache读写性能很是高，QPS（每秒查询） 1W以上，数据持久化使用Redis
	  不持久话，二者均可以。
3.SSD代替机械硬盘
	a.日志和数据分开存储，日志顺序读写放入机械硬盘 ，数据随机读写放在SSD中
	b.调参数 innodb_flushmethod = O_DIRECT告诉操做系统禁用缓存，fsync方式，
      数据刷入机械硬盘。innodb_io_capacity = 10000,控制mysql中一次刷新脏页的数量
	  SSD使得IO加强应增大该值。
4.SSD+SATA混合存储  FlashCache FaceBook开源项目 在文件系统和设备驱动之间加了一层
  缓存对热数据缓存。

六.架构优化

1.分表
	a.水平拆分
	  数据分红多个表
	b.垂直拆分
	  字段分红多个表
	c.MyISAM MERGE存储引擎， InnoDB用alter table
2.读写分离
  读是一些机器，写是一些机器。二进制文件的主从复制，延迟解决方案
3.分库
	MyCat部署，工做流程。

七.SQL慢查询分析 调参数

八.活用存储结构

内容表 id user_id content  分红索引表（字段）  内容表（key,放数据）

九.故障排除案例

APP搜索商家,后台数据库load居高不下
解决方案：like 查询无索引致使，sphinx Coreseek开源全文检索。