MySQL优化-初始MySQL

MySQL优化-初始MySQL

提问的艺术
咨询具体SQL效率问题,请提供
1.执行show create table t1\G 和 show index from t1;
2.执行explain select ... (如果是update/delete也改成select风格)
3.执行show processlist;

咨询MySQL性能问题,请提供
1.(负载较高时) 执行系统指令 top
2.(负载较高时) 执行系统指令 vmstat -S m 1 20
3.(负载较高时) 执行MySQL指令 show processlist;
4.执行MySQL指令 show global variables;
5.执行MySQL指令 show global status;
将上述信息整理齐全,发布到http://t.zhishutang.com, 或qq群:91895469

LOGO吉祥物,海豚,名字叫Sakila.
创始人 Michael Widenius (昵称:Monty)
大女儿叫"My",由此得名MySQL
MySQL AB公司,1995年始于瑞典,第一个版本发布于1995.5.23
2008年被sun收购,2010年sun被Oracle收购。
2005年Oracle收购Innobase OY.
我的第一个MySQL版本是5.6.x(2016年)

MySQL简史    
    MySQL是一个关系型数据库
    支持多平台
    开源、免费,基于GPL协议
    双授权,区分企业版、社区版
    MySQL本身是个数据库框架
    三层结构:连接层、server层、引擎层
    支持多种连接方式,C/C++/PHP/Python/Java/C#等
    支持多种存储引擎,可自行开发插件、UDF

最新版本号为啥从5.7直接跳到8.0了?
    6.0已经用过了
    7.0是mysql ndb cluster专用
    所以,只能从8.0开始了

从其他数据库迁移到MySQL
    Oracle、SQL Server迁移到MySQL
    一些变化
        不再使用存储过程、视图、定时作业
        表结构变更,如采用自增id做主键,及其他语法变更
        业务SQL改造,不使用窗口函数,CTE等功能
        制定MySQL业务开发规范
数据迁移
    MySQL Workbench、MySQL原生的load data infile、SQLyog、Navicat、Sybase Powerdesigner
    OGG
    ODBC/JDBC
    datax
    otter + canal
    全量一次性复制 + 增量变化应用
    一般建议自己开发迁移工具,有更好的定制效果
数据校验
    yuyong (for Oracle)

迁移注意事项
    数据类型差异
    字符集不同
    主键规则不同
    (物化)视图、存储过程/函数不同
    堆表、IOT表差异
    迁移过程中增量数据的追加
    最后的数据校验

I_S是 information_schema的简写
P_S是 performance_schema的简写
IBP是 innodb_buffer_pool的简写

Hardware
    体系结构
    阵列卡
    硬盘
    SSD/PCIe SSD
OS
    初级SA及以上水平
    脚本能力
    自动化运维
    基础安全能力
Database
    索引
    MVCC
    并发控制
    执行计划
Others
    云服务
    其他数据库
    大数据
    NoSQL
    软实力(沟通、表达、情商)

1.PC Server: DELL、HP、IBM、华为、浪潮、联想、曙光等
2.阵列基础知识(阵列级别、WB/WT、BBU、CACHE Policy)及如何优化。
    WB, Write Back
    WT, Write Through
    正常滴,使用机械盘时,WB模式下至少比WT时的IOPS高一倍以上。
3.SATA SSD、PCIe SSD、NVMe SSD区别
4.服务器硬件健康状况监控,常见故障处理方案
5.硬件指标
    CPU: 主频、多核、超线程、L1-L3 CACHE、延时
    内存: 容量、带宽、延时
    DISK IO: 转速、IOPS、吞吐、延时
    网络: 速率、延时
    SSD: 擦写次数、总写入字节数、写放大、平均无故障时长、MLC/SLC
6.如何估算IOPS指标
7.顺序读写,随机读写

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/

理解MySQL特点:
单进程,多线程。
每个连接只能用到一个逻辑CPU。
每个Query/SQL只能用到一个逻辑CPU。
在超高并发且多垃圾SQL情况下,对MySQL而言是个大灾难。
不适用MySQL5.1以前的版本,因为多核CPU利用更差。
MySQL新版本高并发可以很好利用多核CPU。
使用/优化建议:
    使用新版本,抛弃旧版本。
    用高主频、多核CPU。
    不跑复杂SQL。
    事务及早结束。

MySQL5.7起可在线动态调整IBP,也不建议设置过高或过低。
每个session buffer诸如sort/join/read buffer/tmp table,不要设置过高。
使用/优化建议:
    IBP一般最高设置物理内存的50%-70%。
    加大物理内存,减少物理I/O,提高TPS。
    session级buffer按需分配,因此适当就好,无需过大。
    禁用所谓的高速查询缓存(query cache),是影响高并发性能的鸡肋。
    随着MyISAM引擎逐步被抛弃,key buffer只需设置非常小。

磁盘I/O是数据库应用场景最大的瓶颈。
OLTP业务场景中,绝大多数是随机I/O读写。
使用、优化建议:
    加大物理内存,减少物理I/O。
    采用高速磁盘设备。
    适当创建索引,减少随机读。
跑MGR环境时,一定要跑在千兆网络环境里。

不存图片、文件、长文本等大对象数据。
不跑复杂SQL,表达式运算、函数运算等。
不跑长事务。
不跑全文检索。
不支持bitmap索引。
不支持hash join。
MySQL 8.0 之前不支持统计直方图。

开源、免费、跨平台。
和Linux深度结合。
特别适合互联网应用场景。
入门学习成本低。
社区庞大,生态完善。
人才储备充足。
新版本新功能越来越赞,值得信赖。
总之,可以放心投入MySQL。

多用谷歌,少用百度。

小结:
    用更好的CPU、更多的内存、更好的I/O设备跑MySQL。
    不存大对象数据。
    不跑大事务、垃圾SQL、长事务。
    不做复杂SQL运算。

MySQL分支版本
Oracle MySQL,官方版本

MariaDB
    创始人Monty另起灶炉的新分支。
    主要是在Server层做了一些改进、增强,以hash join著称。
    最早引入线程池、审计、PAM认证、GTID、InnoDB加密、虚拟列、JSON类型、多源复制、并行复制、CTE、窗口函数、CHECK约束、DEFAULT之表达式等新功能。
    集成ColumnStore、MyRocks、TokuDB、Spider等多种引擎、插件。
    集成了MaxScale中间件解决方案。
    最新的Oracle MySQL 8.0 发布后,metadata全部采用InnoDB引擎,MariaDB暂时无法兼容。
    官网,https://www.mariadb.com

Percona
    Percona Server For MySQL,基于官方版本附加性能提升以及管理增强。也集成了TokuDB、线程池、审计、PAM认证等功能。
    Percona XtraDB Cluster(PXC),基于gelera高一致性架构。
    Percona TokuDB,高性能压缩存储引擎。
    Xtrabackup,备份工具。
    Percona-toolkit,DBA附加工具。
    PMM,监控工具。
    官网,https://www.percona.com

MySQL社区版基于GPLv2,企业版则是商业的。而MariaDB只能基于GPLv2,MaxScale商业,ColumnStore基于GPLv2。
MariaDB更激进,更乐于接受社区提交的代码。Oracle MySQL相对保守,几乎很少有直接采用社区贡献的代码(腾讯快速加列功能除外)。
MariaDB和Oracle MySQL的GTID模式不能兼容。
Percona则是几乎紧跟追随Oracle MySQL的节奏。

MariaDB优势:
    ColumnStore
    MyRocks
    TokuDB
    Sequence
    Spider
    thread pool

同一个统计SQL:
    InnoDB      上运行 25.36s
    ColumnStore 上运行 0.17s
    infobright  上运行 1min24.09s

小结:
三个主流分支Oracle MySQL,Percona MySQL,MariaDB。
优先选择顺序从左到右。
选择Percona还是MariaDB需要认真权衡利弊。

猜你喜欢

转载自www.cnblogs.com/zhouwanchun/p/12653160.html