mysql特性及部署规范

--分支版本，mysql对cpu，内存，io子系统资源利用特点
--oracle mysql，mariadb，percona server
--部署规范建议，系统安装，mysql安装，其他规范
互联网业务为什么选择MySQL，主要是因为：
1、不要复杂事务支持，RR级别下，辅助next-key lock，就可以满足高一致性要求了；
2、真的需要物化视图时，可以采用触发器的方式变相实现；
3、不支持函数索引、hash join、bitmap索引，虽然是硬伤，但大部分互联网应用都不需要这么强的功能需求，
或者可以对产品需求进行改造；
4、查询优化器在持续改进中，需要一个过程，而且绝大多数都是简单应用，整体来说还好；

评论数量，计数器，就存储在redis
云数据库
文档类型的
大数量运算
基于LBS的引用--地理位置应用
都可以采用mongodb

MySQL利用硬件资源特点
CPU的利用特点
• <5.1，多核心支持较弱
• 5.1，可利用4个核
• 5.5，可利用24个核
• 5.6，可利用64个核
• 每个连接对应一个线程，每个并发query只能使用到一个核
内存利用特点：
• 类似ORACLE的SGA、PGA模式，注意PGA不宜分配过大
• 内存管理简单、有效。在高TPS、高并发环境下，可增加物理内存以减少物理IO，提高并发性能
• 官方分支锁并发竞争比较严重，MariaDB、Percona进行优化
• 有类似ORACLE library cache的query cache，但效果不佳，建议关闭
• 执行计划没有缓存（类似ORACLE的library cache）
• 通常内存建议按热点数据总量的15%-20%来规划，专用单实例则可以分配物理内存的50~70%左右
• 类似K-V简单数据，采用memcached、Redis等NOSQL来缓存
磁盘：
• undo log的I/O特征：顺序写，随机读；
• Redo Log、Binlog的I/O特征：顺序写，顺序读；
• 数据文件的I/O特征：随机写，随机读；
• OLTP业务以随机IO为主，建议加大内存，尽量合并随机IO为顺序IO
• OLAP业务以顺序IO为主，极大内存的同时增加硬盘数量提高顺序IO性能
• MyISAM是堆组织表（HOT），InnoDB是索引组织表（IOT）
• InnoDB相比MyISAM更消耗磁盘空间
3、 MySQL DBA必备知识体系
a) 硬件知识
• PC Server，了解DELL/HP/IBM，以及国产服务器的管理（idrac，ilo，imm）
• 了解阵列卡的工作原理（阵列组成、条带、WB/WT、BBU），以及如何进行优化
• 了解服务器硬件健康状态、性能监控机制
• 了解磁盘的关键技术指标：转速，有条件的也了解下SSD、PCIe-SSD设备（关键指标：擦写次数，总写入字节数，写放大）。
延迟、iops、吞吐、平均无故障时长、Flash颗粒（MLC/SLC）、读/写带宽、读/写延迟、读/写IOPS、寿命（总写入字节数）
i. 计算机体系结构
北桥被用来处理高速信号，通常处理CPU（处理器），RAM（内存），AGP端口或PCI Express,和南桥芯片之间的通信。
南桥芯片负责I/O总线之间的通信，如PCI总线、USB、LAN、ATA、SATA、音频控制器、键盘控制器、实时时钟控制器、高级电源管理等。
NUMA
CPU通过QPI总线直接控制内存
PCIE/PCI-E，PCI-Express是最新的总线和接口标准，由英特尔提出的，代表着下一代I/O接口标准。
它的主要优势就是数据传输速率高，目前最高的16X 2.0版本可达到10GB/s，而且还有相当大的发展潜力。
ii. SAS 和SATA区别
SAS是为了以任务为中心的企业应用程序而设计的，而SATA则是在消费者市场上常见的拥有一般用途的接口
- SAS支持多个启动程序，而SATA不提供这种功能
- SAS是双端口的，而SATA是单端口的。因此，SAS可以在没有额外的硬件的情况下支持多路径I/O。
iii. SSD架构
iv. PCIe SSD和普通SSD的区别
一个是PCIE上进行数据交换（绕过总线），一个是SAS/SATA（经过总线）。
前者带宽更加大，且PCIe SSD一般存储总容量也大很多。
b) 系统知识
i. Linux管理
基础知识、基本操作
常规服务管理技能
网络、安全相关知识
内核相关参数理解

安装规范
a) 系统安装规范
硬件设置
• 偶数盘组成RAID 1+0，FORCE WB策略，CACHE卡越大越好，可将所有CACHE都用于写缓存加速，关闭预读
可将所有CACHE都用于写缓存加速，关闭预读 = FORCE WB 、以及 NORA 的cache策略
--双电源，双电路，ups
• 如果是SSD，建议RAID1（两块不同使用生命周期的盘，降低同时故障的概率），保证数据安全性
DELL服务器的阵列卡为例：
Default Cache Policy: WriteBack, ReadAdaptive, Direct, Write Cache OK if Bad BBU
MegaCli64 -ldsetprop NORA -lall -aall -nolog
NORA = NO readahead
opt/MegaRAID/MegaCli/MegaCli64 -ldsetprop NORA -lall -aall -nolog
WriteBack = WB
ReadAheadNone = NORA
WriteBack + Write Cache OK if Bad BBU = FORCE WB

raid10 ，先做raid1，对2组raid1做raid0
操作系统
• CentOS/RHRL/ORACLE Linux 5.x/6.x x86_64发行版
CentOS、Ubuntu、RHEL，优先建议这三种OS
文件系统
• datadir及backupdir所在分区采用xfs，最起码也要用ext4，# df -T
ioscheduler
• SSD使用noop策略，其他使用deadline策略
最大文件数
• ulimit -n 65535，默认的1024一般都不够用
最大进程数
• ulimit -u 65535，默认的一般都不够用
其他需要注意的地方有
• 关闭selinux
• 设置 vm.swappiness = 0减少swap（ RHEL 7以上设置为10，避免OOM）
• 关闭NUMA，提高内存利用率和CPU性能
• 关闭CPU节能模式，提高CPU性能
datadir
• 单实例 /data/mysql
• 多实例 /data/mysql/yejr_3306 、 /data/mysql/yejr_3307
backupdir
• /backup 或其他独立分区下的目录
其他
• 多实例默认使用 mysqld_multi 来管理
• 默认关键参数
• transaction_isolation = READ-COMMITTED
• innodb_flush_method = O_DIRECT （尤其是从ORACLE转到MySQL的要注意）O_DIRECT，饶过OS page cache，直接写阵列卡
• innodb_file_per_table = 1
• innodb_flush_log_at_trx_commit = 1
• innodb_data_file_path = ibdata1:1G:autoextend
• long_query_time = 1
• log-output=file
• slow_query_log = 1
• lower_case_table_names = 0
[mysql]
prompt="\\u@\\h \\D \\R:\\m:\\s [\\d]&get;
#pager="less -i -n -S"
tee=/home/mysql/query.log
no-auto-rehash
c) 其他规范要点
• 开发环境规范
• 启用log_queries_not_using_indexes
• 设置long_query_time为最小值
• 定期检查分析slow log
• 授权和生产环境一致
• 关闭Query Cache
• 设置较小InnoDB Buffer Pool、key buffer size
• 数据量不能太少，否则有些性能问题无法提前规避

假设有这么一个slow log
# Query_time: 0.01034848 Lock_time: 0.000697 Rows_sent: 1 Rows_examined: 1708000
SET timestamp=1399534522;
select * from global_status_diff;
需要注意：
1、扫描大数据集，但返回很少结果
2、没有LIMIT
3、没有WHERE
4、SELECT *
行为规范
• 批量导入、导出数据须提前通知DBA，请求协助观察
• 推广活动或上线新功能须提前通知DBA，请求压力评估
• 不使用SUPER权限连接数据库
• 单表多次ALTER操作必须合并为一次操作
• 数据库DDL及重要SQL及早提交DBA评审
• 重要业务库须告知DBA重要等级、数据备份及时性要求
• 不在业务高峰期批量更新、查询数据库
• 提交线上DDL需求，所有SQL语句须有备注说明
有SUPER权限的用户，是可以对read-only的slave库写入数据的