数据库的性能优化的一些思考

2019年12月13日 阅读数:57
这篇文章主要向大家介绍数据库的性能优化的一些思考,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。
1,服务器目前的架构 cpu 内存 io 网络
一主 -》 多从(14) 主服务器宕机 切换从服务器慢
监控指标 :qps和tps (慢sql占用cpu时间太长,每一个sql只能是一个cpu执行,qps超高形成阻塞)
并发量和cpu使用率 (链接数被占满,cpu资源耗尽出现宕机)
磁盘IO
网卡IO
大表(千万行数据,文件10g数据,查询条件复杂)
查询慢容易产生慢sql,产生大量的磁盘IO,更改列会很慢,创建索引时间长,主从延迟大
ddl操做会长时间锁表,形成主从延迟,正常数据会被阻塞,大量的连接超时
分库分表:主键选择 跨分区数据查询和统计
数据归档:时间点的选择(历史数据的查询作单独的入口,分离冷热数据,历史数据的统计和计算数据作异步处理)
归档操做的方式选择
大事务(关系型数据库的特性,原子性操做,原子性 一致性 隔离性 持久性)
要么所有成功要么失败回滚,
事务操做前和操做后完整性不能被破坏,
事务未提交以前对事务的操做不可见(未提交读,已提交读(默认隔离级别),可重复读(mysql默认),可串行化)
事务执行完以后持久化到磁盘不会丢失
运行时间比较长,操做数据比较多的事务叫作大事务
锁定的数据太多,形成大量的阻塞和锁超时
回滚所需的时间比较长
执行时间比较长,主从同步延迟太大
 
避免一次处理太多数据(分批处理)
移除没必要要的select操做
 
2,影响性能的几个方面
硬件
服务器系统
存储引擎(插件式的存储引擎选择)
myisam 不支持事务,表级锁
innodb 事务,行级锁 ACID特性
数据库配置参数
表结构的设计和sql语句
3,硬件的影响
cpu 频率和核数,
mysql单条sql没法使用多个cpu,qps:每秒处理sql数量,核数比处理能力重要
内存大小
内存的io大于磁盘不少 热数据 > 可用内存数据
myisam 把索引缓存在内存中,数据经过操做系统缓存
innodb 同时缓存 数据和索引到内存
读减小磁盘io,写减小磁盘io
磁盘IO和网络资源
存储大小,传输速度,访问时间,主轴转速,物理尺寸
RAID技术:磁盘冗余队列,小磁盘组成大磁盘,提供数据冗余保持数据完整性
RAID0 没有冗余和数据修复能力,多个磁盘串联在一块儿,并发写入,容量相加
RAID1 磁盘镜像,生成数据备份镜像,并发写同时备份,磁盘冗余,容量减小50%
RAID5 奇偶校验磁盘阵列,任何数据失效均可以从奇偶校验块中重建
READ10 分片镜像 RAID1+READ0
 
固态硬盘SSD, PCIE SSD 比机械盘有更好的随机读写的性能,更好的支持并发,更容易损坏
SSD SATA接口 直接替换传统磁盘,一样支持RAID技术
PCI-E SSD 没法使用SATA接口,须要独特的驱动配置,贵性能更好
 
适用于大量随机IO,解决单线程负载的IO瓶颈
网络存储NAS和SAN
SAN -》服务器-》SAN 经过光纤访问服务器
缓存 大量顺序读写 随机读写慢
NAS 使用网络链接,经过文件协议 NFS和SMB访问
网络设备 (延迟和带宽)
高性能高代开网络接口设备
多个网卡绑定增长可用性和带宽
网络隔离 内外网隔离 业务隔离
 
总结,64位架构运行在64位系统
并发高的场景cpu核数比频率重要,cpu密集型和复杂sql频率越高越好
选择主办能使用的最高内存,尽量的大
IO子系统 PCIe-》SSD-〉Raid10-》磁盘-〉SAN
3,服务器的影响
mysql比较常见的运行到linux,window对大小写不敏感,强制使用小写
window FreeBSD Solaris Linux
 
centos 参数优化
/etc/sysctl.conf
net.core.somaxconn=65535
net.core.netdev_max_backlog=65535
net.ipv4.tcp_max_syn_backlog=65535
 
net.ipv4.tcp_fin_timeout=10
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
 
net.core.wmem_default=87380
net.core.wmem_max=16777216
net.core.rmem_default=87380
net.core.rmem_max=16777216
 
net.ipv4.tcp_keepalive_time=120
net.ipv4.tcp_keepalive_intvl=30
net.ipv4.tcp_keepalive_probes=3
 
kernel.shmmax=429497295
vm.swappiness=0
 
/etc/security/limit.conf
* soft nofile 65535
* hard nofile 65535
 
/sys/block/devname/queue/scheduler
磁盘调度策略
 
文件系统
windows (FAT NTFS)
linux(EXT3 EXT4 XFS)
 
4,mysql架构
插件式存储引擎,数据处理和存储相分离
cs结构
客户端(java php c ODBC JDBC),负责链接处理,受权认证,安全等,一个链接智能化用到一个cpu,全部的操做都是在一个线程操做
服务层 链接管理()->查询缓存-》查询解析-〉查询优化 全部跨存储引擎的功能都在这一层
存储引擎层 针对于表的,不这对库文件
myisam: mysql5.5只前的默认存储引擎,
系统表,临时表(排序分组操做,数量超过必定大小,由查询优化器创建临时表)使用的存储引擎。
MYD和MYI两个文件存储数据,frm存储表结构。
表级别锁,读写混合的并发性很差;
表修复check table tablename;repair table tablename;
全文索引(mysql5.7以前惟一原生支持全文索引的引擎),对text和blog的前500字符的前缀索引
支持表数据压缩(myisampack),压缩表的只读表不能插入和更新
mysql5.0以前单表最大4G(MAX_Rows AVG_ROW)LENGTH),mysql5.0以后最大256TB
使用场景:非事务应用,只读类型的并发性好,空间类应用(空间函数 5.0以前的必选)
Innodb:mysql默认存储引擎,表空间存储数据,(innodb_file_per_table: on 独立表空间 .ibd , off系统表空间 ibdataX)
.frm和表空间文件
系统表空间没法简单收缩文件大小形成磁盘碎片,独立表空间使用optimize table命令重建表空间收缩文件系统
系统表空间产生IO瓶颈,独立表空间能够同时刷新多个文件数据,mysql5.6以后默认独立表空间
frm存储的是服务器层的数据字典跟引擎无关的,系统表空间存放引擎相关的数据字典,回滚段
事务型存储引擎ACID,redolog和undolog实现;行级锁,在存储引擎层实现,服务层不可见
锁(管理共享资源的并发访问,实现事务隔离),共享锁(读锁),独占锁(写锁)
阻塞:等待其余的锁释放资源,慢查询产生大量的阻塞
死锁:事务相互占用资源,系统自动识别死锁,并释放占用资源较少的事务,使得事务继续运行
show engine innodb status ;//状态检测
除了5.7以前的空间应用和全文索引状况都要默认innodb引擎
 
CSV存储引擎 存储文件.csv文件,一文件方式存储,myisam和innodb是二进制文件存储的
.frm表结构 .csv存储表数据内容 .csm存储表的元数据 数据量 表状态等
全部的列不能是null,不支持索引,不适合作发表和在线处理数据,能够直接对数据进行编辑
适合作数据交换中间表
Archive 以zlib对表数据进行压缩,占用更少的磁盘IO和存储空间,数据问价 .frm和.arz文件
只支持insert和select操做,行级锁,专用的缓冲区,支持高并发插入,只支持自增ID创建索引
适合 日志和数据采集的应用
memory引擎 数据存储在内存中,表结构保持在磁盘,也叫HEAP引擎
支持HASH(默认)和BTREE索引,等于查询时hash索引快,btree索引作范围查找快
全部字段都是固定长度 varchar(10)=char(10)
不支持blog和text字段类型
表级锁,并发性能有影响,max_heap_table_size决定最大表数据
 
系统自动建立:  tmp-table-size 或  max-heap-table-size 
1,超过限制使用myisam临时表 2,未超过如今使用memory临时表
主动建立: create temporary table
 
适用于映射表查找表,保存分析数据的中间表 缓存周期性聚合结果表
federated引擎 提供远程访问mysql服务器上表的功能,本地不存储数据,本地保存表结构和远程服务器的链接信息
默认mysql禁止使用,性能很差。
设置federated=1开启;
适用于 手动统计分析查询
 
存储引擎选择,没有特殊需求innodb是最佳选择
事务支持:innodb最稳定,select和insert 选myisam insert选archive
备份:innodb有在线热备份方案,mysqldump不是热备份(会加锁的逻辑备份)
崩溃恢复 innodb比myisam好不少
特殊引擎特性需求
mysql服务器配置
mysql配置文件 my.conf
参数做用域 全局set global 参数=值
会话 set session 参数=值
内存相关参数:可以使用内存上限(单进程运行)
每一个sql链接的使用内存
(sort_buffer_size 须要排序的sql会分配这部份内存)
(join_buffer_size 每一个线程使用的链接缓冲区,每一个连表分配一个)
(read_buffer_size 读缓冲区 全表扫描myisam时分配,4k的倍数)
(read_rnd_buffer_size 索引缓冲区)
缓存池分配的内存
innodb_buffer_poll_size 缓存索引和数据,延迟写入(合并多个写入一块儿写入磁盘)
总内存 - 单个线程内存*链接数 -系统保留内存 建议服务器内存的75%
key_buffer_size 主要是myisam用,缓存索引,数据依赖操做系统缓存
IO相关的配置参数:性能 安全 作平衡 贵啊
innodb:innodb_log_file_size * innodb_log_files_in_group = 事务日志总大小
innodb_log_buffer_size 事务日志缓冲区秒级持久化
innodb_flush_log_at_trx_commit 0秒级写入chach并flush到磁盘
1每次事务提交都写入cache并flush到磁盘
2每次都写入cache,每秒flush到磁盘
innodb_flush_method=O_DIRECT 操做系统不缓存数据
innodb_file_per_table =1 innodb的表空间
innodb_foublewrite = 1 双写缓存,避免叶没写完整就写到文件中
myisam:delay_key_write OFF ON ALL
安全相关配置:
expire_log_days 指定binlog自动清理的天数
max_allowed_packet 控制mysql可接收的包的大小
skip_name_resolve 禁用DNS查找
syadate_is_now 确保sysdate()返回肯定日期
read_only 禁止super全县用户的写权限
skip_slave_start 禁止slave自动恢复
sql_mode 设置mysql使用的sql模式
(strict_trans_tables, no_engine_subtitution,no_zero_date,no_zero_in_date,only_full_group_by)
其余配置的影响
sysc_binlog 默认为0 ,操做系统决定何时刷新binlog;1,每次事务都会有写binlog操做
tmp_table_size 和 max_heap_table_size 内存临时表的大小,超过就会生产磁盘临时表
max_connections 控制最大链接数
结构设计和sql优化
表的列太多,因为插件式引擎设计,mysql的服务层和引擎层是分离的,在引擎层的api和服务器层须要缓存格式来拷贝数据,而后在服务器层解析转换成各个列。
关联太多的表 10个是极限
OLTP环境不恰当使用分区表
外键的使用 保证数据完整性,效率低,修改和备份时候,要检查约束,额外的锁的开销
 
总结:数据库结构设计 和 sql优化 > 数据库的存储引擎和参数配置 > 系统参数的优化 > 硬件的升级
 
 
5,mysql性能测试
基准测试 直接简单,易于比较,评估服务器处理能力,不涉及逻辑处理
压力测试 正式业务数据进行测试,得到真实的业务系统的压力
指标:TPS QPS 响应时间(最大 最小平均 响应时间 各个时间百分比) 并发请求数量(同时操做的数量 不是同时存在的进程)
收集信息:cpu使用率 IO 网络流量 状态 计数器信息等
工具:ab,mysqlslap(mysql5.1以后自带),sysbench ,Super Smack
 
6,表结构设计对性能的影响
良好的数据库逻辑设计和物理设计是数据库良好性能的jichu
目标:减小数据的冗余,避免数据的依赖维护异常,节约数据的存储空间,提升查询效率
步骤:需求分析(存储需求,处理需求,安全性和完整性)
逻辑设计(设计数据的逻辑存储结构,数据实体之间的逻辑关系,解决数据冗余,维护数据异常)
物理设计(表结构的设计)
维护优化(根据实际业务状况进行索引,存储结构的优化)
 
表逻辑设计 范式+反范式结合 = 高性能
范式:...... 减小冗余,体积小,更新快
查询关联表多,查询效率低;索引优化更加困难
反范式化: 空间换时间,更加方便查询条件的设计,提升查询效率,减小关联表,更好的索引优化(覆盖索引等)
物理设计
命名规范:库,表,字段的命名规范,不能用大小写区分,可读性,表意义的表达,完整单词
存储引擎:没特殊要求就用innodb,上边写过各个引擎的使用场景
表字段:合适的数据类型
数字》日期〉二进制》字符 (字符的比较排序等是根据字符集排序规则相关的,数字二进制日期等不用二进制大小能够直接比较)
同时占用空间越小越好(数据处理以页为单位的 innodb是16k,列越小每页的数据量就越多)
tinnyint 1字节 -128,128 0,255
smallint 2字节
mediuint 3字节
int 4字节
bigint 8字节
 
float 4字节
double 8个字节
decimal 每4字节存储9个数字,小数点占一个字节
 
varchar 变长字符串,只占用必要的存储空间
额外的字节存储字符串长度,列的长度超过255须要两个字节存储字符串长度,最大就是65535长度,因此不可能用3个字节
使用最小符合需求的长度(改变长度会锁表,5.7以后不超过255不会锁表)
varchar(5)和varchar(200)性能比较,mysql在加载数据到内存中使用的是固定宽度,缓存和内存临时表的时候消耗的内存比较多
适合存储长度比较分散的数据,不多被更新的数据(字符长度变化,可能引发存储页的分裂,产生磁盘碎片),多字节字符集
char 固定宽度字符串,末尾的空格会被过滤删除,最大宽度255
适合存储长度比较集中,长度短小的字符串,常常被更新的字符列
日期类型 datetime类型 以yyyy-mm-dd hh:mm:ss 存储,与时区无关,占用8个字节存储空间
date 和 time 类型
timestamp类型 时间戳,显示格式yyyy-mm-dd hh:mm:ss,只占用4个字节,依赖时区,自动修改更新
存储空间比字符串少,日期能够对比,日期函数方便计算;不要用int来代替timestamp存储时间,并无什么好处
7,mysql架构设计
主从复制:分担mysql的读负载,高可用,灾难恢复备份,经过二进制日志同步数据,异步处理,有延迟
二进制日志增量进行复制,不须要太多带宽,基于行的复制在大批量修改时会带来带宽压力
mysql的二进制日志,慢查询日志,通用日志属于服务层日志,innodb的重作日志和回滚日志属于引擎层日志
二进制日志:记录了mysql数据库的修改事件,增删改事件和表结构变化
binlog_format=STATEMENT 基于段的日志格式,记录sql和上下文信息,日志量少,节约磁盘和网络io
可是使用非肯定性函数,致使上下文信息没法肯定的状况时没法复制的、
binlog_format=ROW 基于行的日志格式 默认格式 官方推荐,记录每行数据的修改
更加安全的复制,复制的效率高,下降主从延迟时间
日志的量比较大,binlog_row_image = FULL | MINIMAL | NOBLOB
binlog_format=MIXED 混合行和段的日志格式 系统根据sql内容必定的算法肯定
 
主从复制过程:
1,开启主服务器二进制日志,主服务器将写入更新写入二进制日志
2,从服务器读取主服务器二进制增量写入到relay_log中,io线程,转储线程
3,从服务器从新执行relay_log的内容
基于日志的复制创建过程:初始化从库数据(mysqldump 等工具)-》启动复制(指定 master 用户 密码 二进制文件 偏移量)
基于GTID的复制:GTID全局事务ID,每一个主库上提交的事务生成惟一ID,从服务器会告诉主服务器已执行的事务的GTID值,主库会告诉从哪些GTID事务没有被执行。
故障处理麻烦,没有skip冲突的操做
GTID = source_id:transsction_id
 
mysql5.7以后支持多主多从
一主多从 mysql5.7以前一直支持
配置简单,
多个从库分担读负载,分担主库的读负载
不一样的业务使用不一样的从库,不一样的业务使用不一样的索引
双主复制 互为主从
容易产生冲突,尽可能分开每一个库操做的表
主备复制 高可用方案
一台mysql只读,作热备份,主库故障才会切换成主服务器
一台mysql作主服务器,切换后做为备份服务器的从库
主从延迟 主从延迟不可避免
主库写入二进制的时间(大事务),控制事务的大小,分割成小事务
二进制的传输时间(日志量,磁盘IO,网络带宽),设置给予MIXED的日志格式
从库重放sql,单线程串行处理重放sql(主库的并发写入从库变成串行),mysql5.6后支持单库的多线程复制
mysql5,7支持逻辑时钟的多线程复制
主从复制中断
数据损坏丢失,主从的二进制日志损坏
从库数据被修改,形成数据冲突
不惟一的server_id,server_uuid
 
高可用 High Availability 缩短故障和系统维护的停机时间,提升可用性
服务器磁盘空间耗尽,性能糟糕的sql,表结构索引没有优化,人为操做失误,主从故障等
创建完整的监控系统,备份数据的恢复测试,及时归档和清理不须要的数据
增长系统的冗余,避免单点故障,主从切换故障转移
 
单点故障
利用SUN共享存储或DRDB磁盘镜像解决mysql单点故障
多写集群(pxc)或NDB集群解决单点故障
主从复制来解决单点故障
MMM(perl):监控管理mysql主主复制的拓扑,切换主备服务器的切换和故障转移,提供读写虚拟ip
同一时间只有一台主mysql对外服务,其余的事只读模式
监控主从中断,延迟过大时,进程故障转移
MHA(perl) : 监控主从复制的拓扑,切换主从服务器完成故障转移
监控主服务器是否可用,不能够就从众多的从服务器选举出一个作主服务器
读写分离 负载均衡
写操做在主服务器进行,读操做在多个从库进行负载均衡
程序实现读写分离,更灵活控制链接主从数据库,直接链接效率高,可是增长工做量程序复杂,人为控制容易出错
读写中间件实现 mysql-proxy maxScale 根据语法分析解析出时读操做仍是写操做,存储过程等直接算主操做,多程序透明,节约开发成本;可是增长了中间层,对查询效率损耗很大,对延迟敏感的业务没法在主库执行
负载均衡:程序轮循,软件(LVS Haproxy MaxScale) ,硬件F5等
 
8,索引查询的优化
索引做用是快速查找到须要的数据(太多,太少的索引都会损耗性能),mysql在存储引擎层实现的索引,不一样的存储引擎索引的使用是不同的;减小存储引擎扫描的数据量(innodb的每次io以页为单位默认16k),帮助排序避免临时表的产生,把随机i 哦转变为顺序io。
同时,索引会增长更新插入成本,要维护索引和统计信息,innodb引入了插入缓存把屡次插入操做合并操做;同时mysql的查询优化器会分析索引选择合适的索引,太多的索引也会增长查询优化器的时间。
 
b-tree索引:以B+树的结构存储数据,是一个平衡查找树。能加快查找数据的速度,更加合适范围查找
每一个叶子到根的距离是相同的,每一个节点按照键值的大小顺序存放
全值匹配查询,匹配最左前缀查询,匹配列前缀的查询,匹配范围值的查询,精确匹配左前列并范围匹配下一列,索引覆盖,order by 排等;
not in, != ,<> 等否认查询在b-tree不会用到索引(网上查的待求证 跟引擎有关)
索引列上不能使用表达式和函数
innodb 索引最大大小不能超过767个字节,myisam是1000个字节,大字符串要使用前缀索引,前缀索引就要考虑到索引的选择性
联合索引 mysql5.0以前一条sql只能使用到一个列上的索引;mysql5.0以后引入了索引合并,能够合并多个列上的索引进行过滤,可是须要更多的内存和磁盘IO来缓存这些索引获取的数据,联合索引更好;
列的顺序:常常被使用的列优先,选择性高的列优先,宽度小的列优先
覆盖索引 除了where条件以外,能够直接经过索引获取查询的数据,也就不必去读取数据行的数据了,避免innodb主键索引的二次查询,避免myisam的系统调用
 
hash索引:基于hash表实现,只有查询精确匹配到hash索引全部的列才会用到索引,存储引擎会为每一行计算hash码,hash索引存储的就是hash码,就是说查找会很快,必须二次查找;存储顺序是按照hash码的大小存储的,不能用于排序、范围查找等;hash冲突
 
索引优化排序:经过索引扫描数据,索引的顺序和order by字段彻底一致,排序方向也要彻底一致,连表查询必须在主表中
索引优化锁:减小锁定的行数量,加快处理速度,加快行释放的速度
 
删除重复和冗余的索引,查找不会被使用的索引,更新索引的统计信息,减小索引碎片(analyze table table_name, optimize table会锁表)
 
9,sql查询的优化
获取性能有问题的sql:经过用户反馈,慢日志获取,实时获取性能有问题的sql
慢日志 开销主要是磁盘的IO和磁盘存储空间
慢查询开启 slow_query_log
慢查询日志存储路径 slow_query_log_file
慢查询日志sql时间伐值 long_query_time
是否记录未使用索引的sql log_queries_not_using_indexes
mysqldumpslow ,pt-query-digest慢日志分析工具
实时获取有问题的sql show processlist
infomation_schema 数据库下的processlist表:SELECT user, host, time, command, time FROM [mysql|information_schema].processlist WHERE user = 'me' and state IS NOT NULL;
 
mysql的执行sql的生命周期分析
客户端经过mysql的接口发送sql给服务器
这个影响微乎其微
 
服务器检查查询缓存是否命中该sql,命中则直接返回结果
打开查询缓存,优先查询缓存是否命中,经过一个大小写敏感的hash查找实现,hash是全值匹配,因此sql必须彻底同样,每次更新查询缓存涉及的表时缓存都会被刷新,并且在缓存查询是否命中时候会对缓存加锁,在并发高和读写太频繁的系统中极可能是下降查询处理效率
query_cache_type = ON | OFF | DEMAND
query_cache_size 查询缓存内存大小1024 * n
query_cache_limit 查询缓存可存储的最大值
query_cache_wlock_invalidate 数据表锁住是否返回缓存中的数据 默认关闭
query_cache_min_res_unit 查询缓存分配的内存最小单位
在sql上加sql_no_cache 不去查询缓存
 
服务器对sql进行解析,预处理,优化器生成执行计划
mysql的解析器经过关键字对mysql进行语句解析,使用mysql的语法规则和解析查询,生成一颗解析树
预处理是进一步检查解析树是否合法(查询中涉及的表和数据列是否存在,名字别名歧义等)
查询优化器生成查询计划,一条sql可用有不少执行方式,优化器会对每种执行方式存储引擎提供的统计信息进行比较,找到成本最低的计划;可能从新定义表的关联顺序,将外链接转化为内链接,等价变换,将表达式转换为常数表达式,子查询转换为关联表
索引太多会致使优化器耗时太多;
存储引擎提供的统计信息不许确、执行计划的成本骨断可能并非实际执行计划的成本,服务层并不知道存储层的全部信息,那些数据是在内存中仍是磁盘上,那些数据是顺序读仍是随机读,就会错误的选择读区数据少的执行计划
优化器认为的最优结果可能不是想要的(执行时间,资源利用最少)
优化器不会考虑并发问题,也就是锁的问题对执行的影响
优化器会基于一些固定的规则生成执行计划,不会考虑执行成本
 
根据执行计划,调用引擎api查询数据
这个影响微乎其微
返回客户端结果
这个影响微乎其微
 
获取sql执行各个阶段的时间 profile(官方要废弃) performance_schema(mysql5.5官方推荐的性能分析存储引擎)
set profile = 1
执行sql
show profiles;
show profile for query N;
show profile cpu for query N;
...
 
开启performance_schema 会记录全部sql的阶段执行时间监控
update `setup_instruments` SET enabled='YES' where NAME like 'stage&';
update `setup_consumers` SET enabled='YES' where NAME like 'event%';
sql执行优化
大表的数据修改要分批次处理,中间有间隔时间
大表结构的修改(表中的字段类型和宽度)会锁表,先从从服务器修改,再主从切换,再修改老的主服务器再切换回来;
(pt-online-change-schamel)
not in 和 <> 等优化 ,使用连表等方式重写sql
使用汇总表优化查询
 
10,分库分表
分担数据库的读负载,可用作主从读写分离;数据量激增,数据库的性能急剧降低,可用把服务器拆分
把一个实例的多个库分到不一样的数据库
把一个实例中一个库中不一样的表拆分到多个库
表水平拆分到不一样的实例中
分区键的选择,尽可能避免跨分片查询发生,尽量平均分配数据到分片中,热数据也要平均
分区键的hash值取模来分片,范围分片,分区键和分片的映射表来分配数据
redis生成全局id并缓存
 
11,数据库监控
数据库的稳定性决定系统的稳定性,监控软件有nagios和zabbix等。
可用性联通监控 mysqladmin -umonitor_user -p -h ping
telnet ip db_port
代码模拟真实应用链接数据库
监控数据库链接数
数据库性能监控 QPS和TPS
 
数据库的并发数量监控
 
数据库的innodb的阻塞监控
 
主从复制的监控
pt-table-checksum
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

热门标签