数据库优化

前面一篇文章从实例的角度进行数据库优化，通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢，影响业务流程。本文从SQL角度进行数据库优化，提升SQL运行效率。 判断问题SQL 判断SQL是否有问题时可以通过两个表象进行判断： 系统级别表象 CPU消耗严重 IO等待严重 页面响应时间过长 应用的日志出现超时等错误 可以使用 sar 命令， top 命令查看当前系统状态。 也可以通过 Prometheus、Grafana 等监控工具观察系统状态。（感兴趣的可以翻看我之前的文章） SQL语句表象 冗长 执行时间过长 从全表扫描获取数据 执行计划中的rows、cost很大 冗长的SQL都好理解，一段SQL太长阅读性肯定会差，而且出现问题的频率肯定会更高。更进一步判断SQL问题就得从执行计划入手，如下所示： 执行计划告诉我们本次查询走了全表扫描 Type=ALL ，rows很大(9950400)基本可以判断这是一段"有味道"的SQL。 获取问题SQL 不同数据库有不同的获取方法，以下为目前主流数据库的慢查询SQL获取工具 MySQL 慢查询日志 测试工具loadrunner Percona公司的ptquery等工具 Oracle AWR报告 测试工具loadrunner等 相关内部视图如v$sql、v$session_wait等 GRID

优化的分类： （实例优化+库的优化=数据库优化） 一、实例的优化 二、库的优化 三、sql的优化 数据库性能问题，95%由用户所写的sql引起，其他由库引起。 优化步骤： 1、定位问题 1>通过v$ 动态试图 2>通过oem性能菜单 3>通过awr出一个报表 4>oracle内部的一些sql报表 5>oracle内部的addm工具 6>外部工具spoolgnignt 7>自己写一些脚本，定位数据库的一些问题 2、优化 1>程序设计阶段去优化----程序上线之前对数据库进行优化，代价最低，效果最好 指定表空间的大小，表空间的对象可以放到不同的磁盘空间，列的主外键。是否需要设置为自动增长。数据文件放到写性能比较好的磁盘，日志文件也放到写性能比较好的磁盘，控制文件放到读写性能比较好的磁盘 2>程序上线时进行优化 创建索引，创建分区表 3>系统上线以后进行优化 ---基本处理的都是这一阶段，代价高，效果不一定很好 网络的优化，数据库的内存不合理 3、如何优化 从上到下的优化，首先优化应用程序---实例（SGA|PGA）---系统---优化硬件（内存） 4、谁来优化---优化是大调整，需要多部门参与 应用程序有问题------程序开发人员-----DBA告诉他怎么改，问题在哪里 swap设置不合理----系统工程师的参与-----需要达到什么要求，必须告诉系统工程师 数据文件，日志文件的迁移

数据库命令规范 • 所有数据库对象名称必须使用小写字母并用下划线分割 • 所有数据库对象名称禁止使用 MySQL 保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） • 数据库对象的命名要能做到见名识意，并且最后不要超过 32 个字符 • 临时库表必须以 tmp_为前缀并以日期为后缀，备份表必须以 bak_为前缀并以日期 (时间戳) 为后缀 • 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低） 数据库基本设计规范 1. 所有表必须使用 Innodb 存储引擎 没有特殊要求（即 Innodb 无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用 Innodb 存储引擎（MySQL5.5 之前默认使用 Myisam，5.6 以后默认的为 Innodb）。 Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好。 2. 数据库和表的字符集统一使用 UTF8 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。 3. 所有表和字段都需要添加注释 使用 comment 从句添加表和列的备注

在设置外键字段时需要注意： 当你使用django2.x的版本时候，在建立外键关系时，需要你手动添加几个关键点参数 models.cascade #设置级联删除 db_constraints 数据库查询与优化 only和defer orm内所有的语句操作，都是惰性操作：只会在你真正需要数据的时候才会走数据库，如果你单单只写orm语句是不会走数据库的。这样设计的好处在于减轻数据库的压力。 res = models.Book.objects.values('title') #普通查询方式 获取到的结果是列表套字典 res1 = models.Book.objects.only('title') #结果是一个个对象，可以直接点属性获取到属性值 print(res) print(res1) only和普通查询的不同就是能直接获取到对象，除了可以获取到上面的title属性值，还可以获取到该对象其他的属性值。但是也有优缺点，看下面的例子。 res1 = models.Book.objects.only('title') for r in res1: print(r.title) #只走一次数据库查询 print(r.price) #每取一次数据就走数据库一次 r.title r.price only总结：当你获取一个不是only括号内指定的字段的时候，不会报错，而是会频繁的走数据库查询

MySQL数据库 是一种小型关系型数据库管理系统，MySQL数据库的 优化 是MySQL数据库操作过程中非常重要的工作，MySQL数据库的优化能够实现MySQL数据库操作的简便。 第一步： 1:磁盘寻道能力,以高速硬盘(7200转/秒),理论上每秒寻道7200次.这是没有办法改变的,优化的方法是----用多个硬盘,或者把数据分散存储. 2:硬盘的读写速度,这个速度非常的快,这个更容易解决--可以从多个硬盘上并行读写. 3:cpu.cpu处理内存中的数据,当有相对内存较小的表时,这是最常见的限制因素. 4:内存的限制.当cpu需要超出适合cpu缓存的数据时,缓存的带宽就成了内存的一个瓶颈---不过现在内存大的惊人,一般不会出现这个问题. 第二步: (本人使用的是学校网站的linux平台(Linux ADVX.Mandrakesoft.com 2.4.3-19mdk )) 1:调节服务器参数 用shell>mysqld-help这个命令声厂一张所有mysql选项和可配置变量的表.输出以下信息: possible variables for option--set-variable(-o) are: back_log current value:5 //要求mysql能有的连接数量.back_log指出在mysql暂停接受连接的时间内有多少个连接请求可以被存在堆栈中 connect

工具概要 如果你的数据库应用系统中，存在有大量表，视图，索引，触发器，函数，存储过程，sql语句等等，又性能低下，而苦逼的你又要对其优化，那么你该怎么办？哥教你，首先你要知道问题出在哪里？如果想知道问题出在哪里，并且找到他，咱们可以借助本文中要讲述的性能检测工具--sql server profiler（处在sql安装文件--性能工具--sql server profiler） 如果知道啦问题出现在哪里，如果你又是绝世高手，当然可以直中要害，写段代码给处理解决掉，但是如果你不行，你做不到，那么也无所谓，可以借助哥的力量给你解决问题。哥给你的武功的秘诀心法是---数据库引擎优化顾问（处在sql安装文件--性能工具--数据库引擎优化顾问） sql server profiler功能 此工具比柯南还柯南，因为他能检测到数据库中的一举一动，即便你不动他，他也在监视你，他很贱的。他不但监视，还监视的很详细，有多详细一会再说，还把监视的内容记录到数据库或者是文件中，给你媳妇告状说你把数据库哪里的性能搞的多么不好，不过他也会把好的给你记录下来，好与不好这当然需要你来分析，其实他也是个很2的柯南。 数据库引擎优化顾问功能 此武功，乃上乘武功。像张无忌的乾坤大挪移，先是接受sql server profiler检测出来的sql，视图，存储过程，数据结构等等，然后他再自己分析，然后再在怀中转两圈

某年某月某日的一个下午，接收到监控服务器的一条告警短信： 尊敬的运维工程师 XX，你好： “192.168.136.200”数据库服务器 CPU 异常，CPU 使用率 98.7%，请尽快处理。 看到这个消息浑身一紧，赶紧掐灭手中的烟，跑回办公室。 以上段子纯属捏造，如有雷同，我反正是不改。 言归正传，本文是记录一次对达梦数据库的优化过程。 处理问题的第一步，是需要了解当前服务器的状况，我们通过以下两种手段确认服务器瓶颈。 系统状况 通过服务器性能监控大盘观察当前系统性能 通过上图我们看出 CPU 基本耗尽，IO 飙升。 通过 sar 命令观察服务器实时状态 sar 10 3 确认 CPU 被耗满，没有空闲。 通过我的细致观察，发现服务器 CPU 被耗满。接下来需要查看数据库服务器的配置参数是否合理，是否有慢查询脚本。 参数优化 查看 dm 配置文件 cd /dm7/dmdbms/devdb cat dm.ini | grep -E "MEMORY_POOL|MEMORY_TARGET|BUFFER" 发现数据库参数配置为安装时候的默认配置，参数不合理，需要优化参数配置。 备份原配置文件 cp dm.ini dm.ini.bak 修改配置 修改如下几个关键参数，根据之前文章 数据库优化-实例优化 中的表格进行优化（ps：当前数据库内存 2G） 参数 优化建议 优化后的值，单位 M

MySQL性能 最大数据量 最大并发数 查询耗时0.5秒 实施原则 数据表设计 数据类型 避免空值 text类型 索引优化 索引分类 优化原则 SQL优化 分批处理 不做列运算 避免Select * 操作符<>优化 OR优化 IN优化 LIKE优化 JOIN优化 LIMIT优化 其他数据库   博主负责的项目主要采用阿里云数据库MySQL，最近频繁出现慢SQL告警，执行时间最长的竟然高达5分钟。导出日志后分析，主要原因竟然是 没有命中索引和没有分页处理 。其实这是非常低级的错误，我不禁后背一凉，团队成员的技术水平亟待提高啊。改造这些SQL的过程中，总结了一些经验分享给大家，如果有错误欢迎批评指正。 MySQL性能 最大数据量    抛开数据量和并发数，谈性能都是耍流氓 。MySQL没有限制单表最大记录数，它取决于操作系统对文件大小的限制。 文件系统 单文件大小限制 FAT32 最大4G NTFS 最大64GB NTFS5.0 最大2TB EXT2 块大小为1024字节，文件最大容量16GB；块大小为4096字节，文件最大容量2TB EXT3 块大小为4KB，文件最大容量为4TB EXT4 理论可以大于16TB 《阿里巴巴Java开发手册》提出单表行数超过500万行或者单表容量超过2GB，才推荐分库分表。性能由综合因素决定，抛开业务复杂度，影响程度依次是硬件配置、MySQL配置

本文转载自博客园： HTTPS ：//www.cnblogs.com/double-K/p/9210982.html 写在前面 　　 SQL SERVER全面优化------- SQL Server诊断系列专家 --------------博客地址---------------------------------- -------------------------------------------------- --- http://www.cnblogs.com/double-K/ 废话不多说，直接开整------------------------------------------ ----------------------------------------------- 用户现象 　　系统慢！保存个单据要好几分钟，很多操作都超时，尤其到下午4点左右各种超时，收款什么的都收不了， 　　查个报表一个小时，下班了还没查完，经常因为系统慢而加班， 　　业务部门已经怨声载道，这个事情已经上报公司高层IT部分压力非常大！ 系统环境 　　首先我们来看一下这个系统配置及现状，为什么说这个客户经典？往下看就知道了... 　　 　　先来看看系统配置： 　　 　　 　　　服务器的配置是：8路24核心做了超线程384个逻辑CPU，内存1T，磁盘全闪 　　　 　　　　没错，相当牛逼得配置！

1. 数据库表结构（设计）优化 合理选择表字段类型类型 int 类型优先于 varchar 类型 优先于 text 类型 varchar （变长字符串）类型优先于 char （不可变长）类型 表分割：对于频繁使用的且数据量增长很快的表进行表的分割 水平分割：将表进行水平条目方向的分割，根据数据的活跃度（被使用程度）将表分为主表、次表等等。主表为活跃度较高的数据。因此分割前要对系统数据活跃度进行调查。将一张大表分割为主表、次表，可缩小、精确查询范围，从而达到优化查询的目的。 垂直分割：从字段方向对表进行分割，对表进行瘦身，删除冗余字段或不常用字段，将这些字段放到其他表中，当需要时连接查询得到需要的数据。 2. sql语句优化 创建并正确使用索引，避免查询放弃使用索引，进行全表扫描 避免在索引字段上使用 is null 和 is not null ――》字段尽量不要允许为null 可以用0或其他特殊字符代替 避免在索引字段上使用 ！= 、 <> 和not in 避免在where子句中对一个有索引的字段和一个没有索引的字段使用or连接 避免使用前导模糊查询 如 like ’%ab%‘ 避免对索引字段进行表达式或者函数操作 避免对索引字段使用变量 组合索引的顺序也会影响到索引的使用情况，从而影响到查询效率 尽量缩小精确查询范围，避免全表扫描 减少返回的数据量（分页），避免返回大量无用数据