标签：完全 读写 事务 集群 out 指令 分离 事物 技术
ok，废话不多说，上干货。
调优思路：
? 0.硬件优化
? 1.数据库设计与规划--以后再修改很麻烦，估计数据量，使用什么存储引擎
? 2.数据的应用--怎样取数据，sql 语句的优化
? 3.磁盘 io 优化
? 4.mysql 服务优化--内存的使用，磁盘的使用
? 5.my.cnf 内参数的优化。
0.硬件优化
CPU—— 64 位、高主频、高缓存，高并行处理能力
内存——大内存、主频高，尽量不要用 SWAP
硬盘——15000转、RAID5、raid10 。 SSD
网络——标配的千兆网卡，10G网卡，bond0，msyql服务器尽可能和使用它的web服务器在同一局域网内，尽量避免诸如防火墙策略等不必要的开销。
1.数据库设计与规划（架构上的优化)
纵向拆解: 专机专用
横向拆解: 主从同步、负载均衡、高可用性集群，当单个 mysql 数据库无法满足日益增加的需求时，可以考虑在数据库这个逻辑层面增加多台服务器，以达到稳定、高效的效果。
2、查询优化
a>建表时表结构要合理，每个表不宜过大；在任何情况下均应使用最精确的类型。例如，如果ID列用int是一个好主意，而用text类型则是个蠢办法；TIME列酌情使用DATE或者DATETIME。
b>索引，建立合适的索引。
c>查询时尽量减少逻辑运算（与运算、或运算、大于小于某值的运算）；
d>减少不当的查询语句，不要查询应用中不需要的列，比如说select * from 等操作。
e>减小事务包的大小；
f>将多个小的查询适当合并成一个大的查询，减少每次建立/关闭查询时的开销；
g>将某些过于复杂的查询拆解成多个小查询，和上一条恰好相反
h>建立和优化存储过程来代替大量的外部程序交互。
3，磁盘 io 规划，io相关的技术
raid 技术：raid0或raid10
4. mysql 服务优化（数据库服务的优化)
保持每个表都不要太大，可以对大表做横切和纵切：比如说我要取得某 ID 的 lastlogin， 完全可以做一张只有“ID和 “lastlog”的小表，而非几十、几百列数据的并排大表。
另外对一个有 1000 万条记录的表做更新比对 10 个 100 万记录的表做更新一般来的要慢
存储引擎：
myisam 引擎，表级锁，表级锁开销小，影响范围大，适合读多写少的表，不支持事物。 表锁定不存在死锁
innodb 引擎，行级锁，锁定行的开销要比锁定全表要大。影响范围小，适合写操作比较频繁的数据表。行级锁可能存在死锁。
5. my.cnf 内参数的优化
对查询进行缓存，一般大致查询都是如此：PHP发出查询请求->数据库收到指令对查询语句进行分析->确定如何查询->从磁盘中加载信息->返回结果
配置查询缓存：
vim /etc/my.cnf 添加：
[mysqld] #在此字段中添加
query_cache_size = 32M
可以在数据库中查看缓存：
show status like ‘qcache%‘;
强制限制mysql 资源设置
您可以在mysqld中强制一些限制来确保系统负载不会导致资源耗尽的情况出现。
在配置文件中添加：
max_connections=500
wait_timeout=10
max_connect_errors = 100
在数据库中用此命令就行验证：show status like ‘max_used_connections‘;
MySQL呢，有太多的调节优化，我们要记住那么多会很吃力，也没有多大意义。其实，只要记住一部分就可以完全满足要求。今天我就写这么多了，这些基本的优化可以解决一部分问题，如果数据很大，就需要做一些集群保证更好的用户体验(读写分离，高可用，搭建缓存数据库)
标签：完全 读写 事务 集群 out 指令 分离 事物 技术
原文地址：https://www.cnblogs.com/sandiandian/p/8886261.html
