《数据库优化可以从哪些维度入手.docx》由会员分享，可在线阅读，更多相关《数据库优化可以从哪些维度入手.docx（30页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、数据库优化，可以从哪些维度入手以下文章;于JAVA日知录，作者飘渺Jam当有人问你如何对数据库进行优化时，很多人第一反应想到的就是SQL优化，如何创建索引，如何改写SQL，他们把数据库优化与SQL优化划上了等号。当然这不能算是完全错误的回答，只不过思考的角度稍微片面了些，太“程序员思维化了，没有站在更高层次来思考回答。那今天我们就将视角拔高，站在架构的角度来聊聊这一问题，数据库优化可以从哪些维度入手？正如上图所示，数据库优化可以从架构优化，硬件优化，DB优化，SQL优化四个维度入手。此上而下，位置越靠前优化越明显，对数据库的性能提升越高。我们常说的SQL优化反而是对性能提高最小的优化。接下来我
2、们再看看每种优化该如何实施。架构优化一般来说在高并发的场景下对架构层进行优化其效果最为明显，常见的优化手段有：分布式缓存，读写分离，分库分表等，每种优化手段又适用于不同的应用场景。分布式缓存有句老话说的好，性能不够，缓存来凑。当需要在架构层进行优化时我们第一时间就会想到缓存这个神器，在应用与数据库之间增加一个缓存服务，如Redis或Memcache。当接收到查询请求后，我们先查询缓存，判断缓存中是否有数据，有数据就直接返回给应用，如若没有再查询数据库，并加载到缓存中，这样就大大减少了对数据库的访问次数，自然而然也提高了数据库性能。不过需要注意的是，引入分布式缓存后系统需要考虑如何应对缓存穿透、
3、缓存击穿和缓存雪崩的问题。 “简单理解一下缓存穿透、缓存击穿和缓存雪崩缓存穿透：它是指当用户在查询一条数据的时候，而此时数据库和缓存都没有关于这条数据的任何记录。这条数据在缓存中没找到就会向数据库请求获取数据。它拿不到数据时，是会一直查询数据库，这样会对数据库的访问造成很大的压力。缓存击穿：一个热点key刚好在某个时间点失效了，但是这时候突然来了大量对这个key的并发访问请求，导致大并发请求直接穿透缓存直达数据库，瞬间对数据库的访问压力增大。缓存雪崩：某一个时间段内，缓存集中过期失效，如果这个时间段内有大量请求，而查询数据量巨大，所有的请求都会达到存储层，存储层的调用量会暴增，引起数据库压力过
4、大甚至宕机。读写分离一主多从，读写分离，主动同步，是一种常见的数据库架构优化手段。一般来说当你的应用是读多写少，数据库扛不住读压力的时候，采用读写分离，通过增加从库数量可以线性提升系统读性能。主库，提供数据库写服务；从库，提供数据库读能力；主从之间，通过binlog同步数据。当准备实施读写分离时，为了保证高可用，需要实现故障的自动转移，主从架构会有潜在主从不一致性问题。水平切分水平切分，也是一种常见的数据库架构优化手段。当你的应用业务数据量很大，单库容量成为性能瓶颈后，采用水平切分，可以降低数据库单库容量，提升数据库写性能。当准备实施水平切分时，需要结合实际业务选取合理的分片键（shardin
5、g-key），有时候为了解决非分片键查询问题还需要将数据写到单独的查询组件，如ElasticSearch。架构优化小结读写分离主要是用于解决“数据库读性能问题水平切分主要是用于解决“数据库数据量大的问题分布式缓存架构可能比读写分离更适用于高并发、大数据量大场景。硬件优化我们使用数据库，不管是读操作还是写操作，最终都是要访问磁盘，所以说磁盘的性能决定了数据库的性能。一块PCIE固态硬盘的性能是普通机械硬盘的几十倍不止。这里我们可以从吞吐率、IOPS两个维度看一下机械硬盘、普通固态硬盘、PCIE固态硬盘之间的性能指标。吞吐率：单位时间内读写的数据量机械硬盘：约100MB/s200MB/s普通固态硬
6、盘：200MB/s500MB/sPCIE固态硬盘：900MB/s3GB/sIOPS：每秒IO操作的次数机械硬盘：100200普通固态硬盘：3000050000PCIE固态硬盘：数十万通过上面的数据可以很直观的看到不同规格的硬盘之间的性能差距非常大，当然性能更好的硬盘价格会更贵，在资金充足并且迫切需要提升数据库性能时，尝试更换一下数据库的硬盘不失为一个非常好的举措，你之前遇到SQL执行缓慢问题在你更换硬盘后很可能将不再是问题。DB优化SQL执行慢有时候不一定完全是SQL问题，手动安装一台数据库而不做任何参数调整，再怎么优化SQL都无法让其性能最大化。要让一台数据库实例完全发挥其性能，首先我们就得
7、先优化数据库的实例参数。数据库实例参数优化遵循三句口诀：日志不能小、缓存足够大、连接要够用。数据库事务提交后需要将事务对数据页的修改刷（fsync）到磁盘上，才能保证数据的持久性。这个刷盘，是一个随机写，性能较低，如果每次事务提交都要刷盘，会极大影响数据库的性能。数据库在架构设计中都会采用如下两个优化手法：先将事务写到日志文件RedoLog（WAL），将随机写优化成顺序写加一层缓存结构Buffer，将单次写优化成顺序写所以日志跟缓存对数据库实例尤其重要。而连接如果不够用，数据库会直接抛出异常，系统无法访问。接下来我们以Oracle、MySQL（InnoDB）、POSTGRES、达梦为例，看看每
8、种数据库的参数该如何配置。Oracle参数分类参数名参数值备注数据缓存SGA_TAGET、MEMORY_TARGET物理内存70-80%越大越好数据缓存DB_CACHE_SIZE物理内存70-80%越大越好SQL解析SHARED_POOL_SIZE4-16G不建议设置过大监听及连接PROCESSES、SESSIONS、OPEN_CURSORS根据业务需求设置一般为业务预估连接数的120%其他SESSION_CACHED_CURSORS大于200软软解析MySQL参数分类参数名参数值备注数据缓存INNODB_BUFFER_POOL_SIZE物理内存50-80%一般来说越大性能越好日志相关Inno
9、db_log_buffer_size16-32M根据运行情况调整日志相关sync_binlog1、100、01安全性最好监听及连接max_connections根据业务情况调整可以预留一部分值文件读写性能innodb_flush_log_at_trx_commit2安全和性能的折中考虑其他wait_timeout，interactive_timeout28800避免应用连接定时中断POSTGRES参数分类参数名参数值备注数据缓存SHARED_BUFFERS物理内存10-25%数据缓存CACHE_BUFFER_SIZE物理内存50-60%日志相关wal_buffer8-64M不建议设置过大过小监
10、听及连接max_connections根据业务情况调整一般为业务预估连接数的120%其他maintenance_work_mem512M或更大其他work_mem8-16M原始配置1M过小其他checkpoint_segments32或者更大达梦数据库参数分类参数名参数值备注数据缓存MEMROY_TARGET、MEMROY_POOL物理内存90%数据缓存BUFFER物理内存60%数据缓存数据缓存MAX_BUFFER物理内存70%最大数据缓存监听及连接max_sessions根据业务需求设置一般为业务预估连接数的120%SQL优化SQL优化很容易理解，就是通过给查询字段添加索引或者改写SQL提高
11、其执行效率，一般而言，SQL编写有以下几个通用的技巧：合理使用索引索引少了查询慢；索引多了占用空间大，执行增删改语句的时候需要动态维护索引，影响性能选择率高（重复值少）且被where频繁引用需要建立B树索引；一般join列需要建立索引；复杂文档类型查询采用全文索引效率更好；索引的建立要在查询和DML性能之间取得平衡；复合索引创建时要注意基于非前导列查询的情况使用UNIONALL替代UNIONUNIONALL的执行效率比UNION高，UNION执行时需要排重；UNION需要对数据进行排序避免select*写法执行SQL时优化器需要将*转成具体的列；每次查询都要回表，不能走覆盖索引。JOIN字段建
12、议建立索引一般JOIN字段都提前加上索引避免复杂SQL语句提升可阅读性；避免慢查询的概率；可以转换成多个短查询，用业务端处理避免where1=1写法避免orderbyrand()类似写法RAND()导致数据列被多次扫描执行计划要想优化SQL必须要会看执行计划，执行计划会告诉你哪些地方效率低，哪里可以需要优化。我们以MYSQL为例，来认识一下执行计划。通过explainsql可以查看执行计划，如：字段解释id每个被独立执行的操作标识，标识对象被操作的顺序，id值越大，先被执行，如果相同，执行顺序从上到下select_type查询中每个select字句的类型table被操作的对象名称，通常是表名，
13、但有其他格式partitions匹配的分区信息(对于非分区表值为NULL)type连接操作的类型possible_keys可能用到的索引key优化器实际使用的索引(最重要的列)从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL。当出现ALL时表示当前SQL出现了“坏味道key_len被优化器选定的索引键长度，单位是字节ref表示本行被操作对象的参照对象，无参照对象为NULLrows查询执行所扫描的元组个数（对于innodb，此值为估计值）filtered条件表上数据被过滤的元组个数百分比extra执行计划的重要补充信息，当此列出现Usingfilesort
14、,Usingtemporary字样时就要小心了，很可能SQL语句需要优化SQL优化实战这里为大家准备了一套SQL优化的综合实战，一步一步带你走一遍完整SQL优化的过程。在执行优化之前我们需要先认识一下原始表及待优化的SQL。原数据库表结构CREATETABLEa(idint(11)NOTNULLAUTO_INCREMENT,seller_idbigint(20)DEFAULTNULL,seller_namevarchar(100)CHARACTERSETutf8COLLATEutf8_binDEFAULTNULL,gmt_createvarchar(30)DEFAULTNULL,PRIMARY
15、KEY(id);CREATETABLEb(idint(11)NOTNULLAUTO_INCREMENT,seller_namevarchar(100)DEFAULTNULL,user_idvarchar(50)DEFAULTNULL,user_namevarchar(100)DEFAULTNULL,salesbigint(20)DEFAULTNULL,gmt_createvarchar(30)DEFAULTNULL,PRIMARYKEY(id);CREATETABLEc(idint(11)NOTNULLAUTO_INCREMENT,user_idvarchar(50)DEFAULTNULL,o
16、rder_idvarchar(100)DEFAULTNULL,statebigint(20)DEFAULTNULL,gmt_createvarchar(30)DEFAULTNULL,PRIMARYKEY(id);待优化的SQL（查询当前用户在当前时间前后10个小时的订单情况，并根据订单创建时间升序排列）selecta.seller_id,a.seller_name,b.user_name,c.statefroma,b,cwherea.seller_name=b.seller_nameandb.user_id=c.user_idandc.user_id=17anda.gmt_createBETW
17、EENDATE_ADD(NOW(),INTERVAL600MINUTE)ANDDATE_ADD(NOW(),INTERVAL600MINUTE)orderbya.gmt_create；原表数据量：原执行时间0.21s，执行速度还挺快原执行计划真是糟糕的执行计划。(全表扫描，没有索引；临时表；排序)初步优化思路：SQL中where条件字段类型要跟表结构一致，表中user_id为varchar(50)类型，实际SQL用的int类型，存在隐式转换，也未添加索引。将b和c表user_id字段改成int类型。因存在b表和c表关联，将b和c表user_id创建索引因存在a表和b表关联，将a和b表selle
18、r_name字段创建索引利用复合索引消除临时表和排序初步优化SQLaltertablebmodifyuser_idint(10)DEFAULTNULL;altertablecmodifyuser_idint(10)DEFAULTNULL;altertablecaddindexidx_user_id(user_id);altertablebaddindexidx_user_id_sell_name(user_id,seller_name);altertableaaddindexidx_sellname_gmt_sellid(gmt_create,seller_name,seller_id);查看
19、优化后的执行时间通过执行计划可以看到，执行时间从0.21s优化成了0.01s，执行时间近乎缩短20倍。查看优化后的执行计划执行计划显示从全表扫描优化成了走索引，rows减少，但是此时出现了2个告警。通过showwarning语句查看告警信息提示gmt_crteate的格式不对，mysql进行了隐式转换导致不能使用索引。继续优化，修改gmtc-create的格式altertableamodifygmt_createdatetimeDEFAULTNULL;再次查看执行时间再次查看执行计划至此，我们的优化过程结束，结果非常完美。SQL优化小结这里给大家总结一下SQL优化的套路：查看执行计划explainsql如果有告警信息，查看告警信息showwarnings;查看SQL涉及的表结构和索引信息根据执行计划，思考可能的优化点按照可能的优化点执行表结构变更、增加索引、SQL改写等操作查看优化后的执行时间和执行计划如果优化效果不明显，重复第四步操作小结我们今天分别从架构优化、硬件优化、DB优化、SQL优化四个角度探讨了如何实施优化，提升数据库性能。但是大家还是要记住一句话，数据库系统没有银弹，要让适合的系统，做合适的事情。求点赞、在看、分享