我们的MySQL
叶金荣,ORACLE ACE(MySQL)
http://imysql.com, 公众号: MySQL中文网, Weibo: @yejinrong
2015.06.26
• 叶金荣,网络常用ID:yejr
• Oracle MySQL ACE
• 国内最早的MySQL推广者
• 2006年创办国内首个MySQL专业技术网站
http://imysql.com
• 资深MySQL专家,10余年MySQL经验,擅长MySQL性
能优化、架构设计、故障排查
我们
agenda
• 简介
• 体系结构
• 高可用/复制
• 性能调优
• 其他
简介
• MySQL是全球最流行的开源关系型数据库,
开源数据库界占有率第二
• MySQL (/maɪ ˌɛskjuːˈɛl/ "My S-Q-L",[6] officially, but
also called /maɪ ˈsiːkwəl/ "My Sequel")
• 伴随着互联网的发展而成长
• 互联网业务标配,好基友LA(N)MP组合
• WEB2.0时代后更是突飞猛进
简介
• 历史
简介
• MySQL发展历程:
 创始人Monty
 1995年建立公司
 2001 ~ 2007 开源飞速发展
 MySQL AB
 2008.01 ~ 2009.04 Sun 10亿美金收购MySQL
 Sun MySQL(5.1 )
 2009.04 ~ now Oracle 74亿美金收购了Sun
 Oracle MySQL(5.5, 5.6, 5.7, 6.0)
简介
• 谁在用MySQL
简介
• 谁在用MySQL
简介
• 目前MySQL主要流行分支
• Percona Server
• 基于InnoDB增加提升性能及易管理性补丁后,形成XtraDB引擎
• 工具:XtraBackup、pt-toolkit系列
• MariaDB
• MySQL创始人Monty创建,目标在于替换现有的MySQL,也包含
了Percona的XtraDB、TokuDB在内的多种实用引擎
• Drizzle
• 重构了MySQL Server层基于云的概念构建,每个功能都可以做为
一个组件译进去,目标:“最小,最快的MySQL版本”
• WebScaleSQL
• 从MySQL 5.6创建的一个分支,由Facebook, LinkedIn,Goolge,
Twitter等4家公司维护
简介
• MySQL历史悠久,并且紧跟行业发展潮流
• 市场占有率规模庞大,且保持扩大趋势
• 不像ORACLE、SQL Server只有单一选择,可以有多种可选方案
• 从5.6版本开始,越来越“像数据库”了
体系结构
• MySQL体系结构
• 分层设计
• 引入存储引擎设计
• MyISAM
• Memory
• Innodb
• TokuDB
• Inforbright
体系结构
• MySQL体系结构
• 分层设计
• 引入存储引擎设计
• MyISAM
• Memory
• Innodb
• TokuDB
• Inforbright
体系结构
• 文件目录
• 配置文件
/etc/my.cnf、/etc/mysql/my.cnf、/usr/local/mysql/etc/my.cnf、~/.my.cnf
• 数据文件
frm、MYI、MYD、ibd、ibdata*、ib_logfile*
• 日志文件
error log、general log、binary log、relay log、slow query log
体系结构
• 文件目录
体系结构
• 文件目录
体系结构
• 存储引擎
引警名 特点 使用建议
MyISAM 早期版本引擎,堆表。在MariaDB用Aria替代,官
方版本中也在减少对MyISAM的使用
尽量少使用MyISAM,MyISAM对
CPU,内存利用率不高,并发支持
不好
Memory 以内存为存储介质,请求速度高,但数据不安全 适用于数据安全要求不高的环境
中,如:临时记数等
Innodb 支持事务,基于MVCC设计,索引组织表,只能有
一个聚集索引
在绝大多数场景中建议使用该引
擎,尤其是OLTP
Tokudb 支持事务,高压缩,高速写入 适用于基于时间有序数据的海量
数据环境
Infrobright 列式存储引擎,高压缩,快速加载数据 适用于OLAP环境
其它 Archive, FEDERATED,CSV,BLACKHOLE` …
体系结构
• 内存结构
体系结构
• 内存结构
体系结构
• MySQL是一个非常灵活的数据库体系,可按需实现引擎
• 可以根据不同的业务或是不同的需求,选用不同的存储引擎
• 不同引擎,各自的配置方案不一样,需要有针对性
• 数据库自身易管理性有待加强
MySQL适用的业务场景及挑战
• MySQL的优点
• LAMP/LNMP天然萌,最佳组合
• 开源、免费,可根据实际需求做定制化、个性化开发
• 快速开发、迭代,修复bug,根据需求引入新功能
• 大量的社区资源可提供支持、帮助(优先google,用so也不要用baidu)
• 跨多平台,Linux、Unix、BSD、windows、Mac都支持
• 特别适合互联网的简单应用
• 最新版本对多CPU核心支持友好,解决了老版本的问题
http://imysql.com http://mysqlsupport.cn 21
MySQL适用的业务场景及挑战
• MySQL的优点
• 灵活的多种数据类型支持,没有太多强制限制,可实现内置自动转化,
且可通过SQL_MODE和其他数据库系统相兼容
• 灵活的SQL用法,不像其他数据库那么死板
• MySQL复制特性使得基于MySQL的架构设计很轻松实现架构快速扩展
• 简单、易用,秒级安装部署完成,可快速上手使用,可快速批量部署、
管理,特别适合互联网爆发增长特点
• 对主流开发语言友好,API完善
• 内存分配灵活
http://imysql.com http://mysqlsupport.cn 22
MySQL适用的业务场景及挑战
• MySQL的缺点
• 无share pool,每个SQL都需要解析,但可利用Query Cache提高效率
• 不支持CBO(目前只有RBO)
• 每个SQL只能使用到一个核
• 随着连接数的增加性能下降严重(但Thread Pool拯救了世界)
• MySQL 5.6后对子查询进一步优化(之前的版本太挫了)
• 暂无hash join特性(MariaDB对此做了优化)
• 不要让MySQL跑复杂应用(BI、复杂关联、复杂子查询等,这不是强项)
http://imysql.com http://mysqlsupport.cn 23
MySQL适用的业务场景及挑战
• 和ORACLE等其他RDBMS的差异
• SQL用法
• 没有hash join
• 子查询比较弱
• 优化器比较弱
• 执行计划比较弱
MySQL适用的业务场景及挑战
• MySQL适用的场景
• 在线OLTP环境,业务模型简单,要求高速响应,并发度高。
• MySQL在固态卡下基于tpcc-mysql测试能达到6万多的TpmC
• 业务库每秒4万多DML(Select+Insert+update+delete)很轻松
• 大数据环境
• Hadoop集群中,后台数据处理大多在MySQL中完成
• 在线海量数据处理,如Tokudb、infobright、infinidb
• 在线交易
• 电商、彩票、在线旅游、物流系统
• 新闻媒体:sina、sohu
• 互动社区:微博、SNS、交友、Linkin
• 其它绝大多数业务场景
http://imysql.com http://mysqlsupport.cn 25
MySQL适用的业务场景及挑战
• 优点多,缺点也不少,但我们更关注优点及其适用性、实用性
• 优点继续发扬光大,缺点不断快速改善中
• 互联网应用的首选
http://imysql.com http://mysqlsupport.cn 26
高可用/复制
• mysql replication
高可用/复制
• mysql semi-replication
高可用/复制
• pxc
高可用/复制
• mha
高可用/复制
• mysql cluster
• 可期待,有待加强
性能调优
• 和其他数据库优化原则通用
• 通常地,I/O仍是最大瓶颈,想尽一切办法提高IOPS或者减少I/O
请求
• 加大物理内存
• 提高CPU主频以及核数
• 95%以上场景都使用InnoDB引擎,并配置足够大的buffer pool(约
占物理内存总量的 50% ~ 70% )
• 更多请移步:一步到位实现MySQL优化 以及 MySQL优化参考
其他
• 单表物理大小不超过10G、行数不过亿
• 平均物理行长度不超过8KB
• 给足buffer pool,关闭鸡肋的query cache
• 活用percona toollkit作为DBA的好帮手

我们的MySQL