数据库优化

数据库优化方案 慢日志查询 1.查看慢查询是否开启 show variables like ‘slow_query%’; show variables like ‘long_query_time’; 2.打开慢查询 set global slow_query_log=’ON’; 3.设置慢查询日志记录文件 set global slow_query_log_file=’/var/lib/mysql/test-10-226-slow.log’; 4.指定慢查询事件 set global long_query_time=1; 数据库的导入导出 导出： mysql dump -u root -p 库名 >导出的文件.sql 导入： mysql -u root -p 库名 来源： https://www.cnblogs.com/huanghongzheng/p/11753928.html

作者: 听风，原文地址: https://www.cnblogs.com/huchong/p/10219318.html 。JavaGuide 已获得作者授权。 数据库命令规范 数据库基本设计规范 1. 所有表必须使用 Innodb 存储引擎 2. 数据库和表的字符集统一使用 UTF8 3. 所有表和字段都需要添加注释 4. 尽量控制单表数据量的大小,建议控制在 500 万以内。 5. 谨慎使用 MySQL 分区表 6.尽量做到冷热数据分离,减小表的宽度 7. 禁止在表中建立预留字段 8. 禁止在数据库中存储图片,文件等大的二进制数据 9. 禁止在线上做数据库压力测试 10. 禁止从开发环境,测试环境直接连接生成环境数据库 数据库字段设计规范 1. 优先选择符合存储需要的最小的数据类型 2. 避免使用 TEXT,BLOB 数据类型，最常见的 TEXT 类型可以存储 64k 的数据 3. 避免使用 ENUM 类型 4. 尽可能把所有列定义为 NOT NULL 5. 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间 6. 同财务相关的金额类数据必须使用 decimal 类型 索引设计规范 1. 限制每张表上的索引数量,建议单张表索引不超过 5 个 2. 禁止给表中的每一列都建立单独的索引 3. 每个 Innodb 表必须有个主键 4.

目录 一：数据库优化机制 （1）惰性查询 （2）only与defer （3）select_related与prefetch_related 一：数据库优化机制 （1）惰性查询 （1）作用 　　（1）ORM查询数据库都是惰性查询 只有当你真正需要数据的时候 才会将数据返回给你 　　（2）其减小了对数据库的操作 降低了数据库的压力 （2）例如： （2）only与defer （1）only:图解 （2）defer图解: （3）select_related与prefetch_related （1）select_related图解: （2）prefetch_related 铛铛铛！！！百科全书来了！！！ QuerySet查询方法大全 ################################################################## # PUBLIC METHODS THAT ALTER ATTRIBUTES AND RETURN A NEW QUERYSET # ################################################################## def all(self) # 获取所有的数据对象 def filter(self, *args, **kwargs) # 条件查询 # 条件可以是：参数，字典，Q

很好的一篇博客，转载 如何优化MySQL千万级大表 原文链接：： https://blog.csdn.net/yangjianrong1985/article/details/102675334 千万级大表如何优化，这是一个很有技术含量的问题，通常我们的直觉思维都会跳转到拆分或者数据分区，在此我想做一些补充和梳理，想和大家做一些这方面的经验总结，也欢迎大家提出建议。 从一开始脑海里开始也是火光四现，到不断的自我批评，后来也参考了一些团队的经验，我整理了下面的大纲内容。 既然要吃透这个问题，我们势必要回到本源，我把这个问题分为三部分: “千万级”，“大表”，“优化”， 也分别对应我们在图中标识的 “数据量”，“对象”和“目标”。 我来逐步展开说明一下，从而给出一系列的解决方案。 1.数据量：千万级 千万级其实只是一个感官的数字，就是我们印象中的数据量大。 这里我们需要把这个概念细化，因为随着业务和时间的变化，数据量也会有变化，我们应该是带着一种动态思维来审视这个指标，从而对于不同的场景我们应该有不同的处理策略。 1) 数据量为千万级，可能达到亿级或者更高 通常是一些数据流水，日志记录的业务，里面的数据随着时间的增长会逐步增多，超过千万门槛是很容易的一件事情。 2) 数据量为千万级，是一个相对稳定的数据量 如果数据量相对稳定，通常是在一些偏向于状态的数据，比如有1000万用户

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配置

Mysql优化 字段设计 遵循三范式。你想想你们公司如果连数据库字段都没有一个规则的话，也就是说你们公司开发都没有一个限制，那么你们是不是开发起来对接起来很麻烦呀，包括后面来的人接手前面的工作，完成搞不懂前一个 人的开发流程。这样维护起来是不是很麻烦？ 原则：定长和非定长数据类型的选择 decimal不会损失精度，存储空间会随数据的增大而增大。double占用固定空间，较大数的存储会损失精度。非定长的还有varchar、text 原则：尽可能使用 not null 非 null 字段的处理要比 null 字段的处理高效些！且不需要判断是否为 null 。 因为 null 在 MySQL中，不好处理，存储需要额外空间，运算也需要特殊的运算符。 语句优化： 语句 1：select * from student limit 9,4 语句 2：slect * from student limit 4 offset 9 // 语句1和2均返回表student的第10、11、12、13行 // 语句2中的4表示返回4行，9表示从表的第十行开始 再 说一下我数据库查询这里的思路，因为逐步写入 EXCEL的数据实际上来自Mysql的分页查询，大家知道其语法是 LIMIT offset, num 不过随着 offset 越来越大 Mysql在每次分页查询时需要跳过的行数就越多

从网上去搜 数据库 优化基本都是从SQL层次进行优化的，很少有提及到数据库本身的实例优化。就算有也都是基于某个特定数据库的实例优化，本文涵盖目前市面上所有主流数据库的实例优化（Oralce、MySQL、POSTGRES、达梦）,按照文章的配置能够将你数据库性能用到80%或以上。 数据库优化方法论 这部分为理论知识，不感兴趣的同学可以直接跳到后面参数配置部分。 数据库优化目标 目标 根据角色的不同，数据库优化分为以下几个目标： 业务角度（关键用户）： 减少用户页面响应时间 数据库角度（开发）： 减少数据库SQL响应时间 数据库服务器角度（运维）： 充分使用数据库服务器物理资源 减少数据库服务器CPU使用率 减少数据库服务器IO使用率 减少数据库服务器内存使用率 指标 SQL平均响应时间变短 优化前：数据库平均响应时间500ms 优化目标：数据库平均响应时间200ms 数据库服务器CPU占用率变少 优化前：数据库高峰期CPU使用率70% 优化目标：数据库高峰期CPU使用率50% 数据库服务器IO使用率变低 优化前：数据库IO WAIT为30% 优化目标：数据库IO WAIT低于10% 数据库优化误区 在进行数据库优化的时候可能会有以下几个误区： 优化之前一定要深入了解数据库内部原理 优化是有“套路”的，照着这些“套路”你也可以很好的完成数据库优化 不断调整数据库参数就可以最终实现优化

作者 | 惨绿少年 链接 | https://clsn.io/clsn/lx287.html 一、前言 MySQL调优对于很多程序员而言，都是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行MySQL的优化之前必须要了解的就是MySQL的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。 今天给大家讲解MySQL的优化实战，助你高薪之路顺畅！ 图片描述(最多50字) 二、优化的哲学 注意：优化有风险，涉足需谨慎！ 1、优化可能带来的问题 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。 保持现状或出现更差的情况都是失败！ 2、优化的需求 稳定性和业务可持续性,通常比性能更重要！ 优化不可避免涉及到变更，变更就有风险！ 优化使性能变好，维持和变差是等概率事件！ 切记优化,应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！ 所以优化工作,是由业务需要驱使的！！！ 3、优化由谁参与 在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员

GO SET STATISTICS TIME ON SELECT count([StyleId]) FROM [dbo].[Ky_Style] SET STATISTICS TIME OFF SET STATISTICS TIME ON SELECT count(*) FROM [dbo].[Ky_Style] SET STATISTICS TIME OFF SET STATISTICS TIME ON SELECT count(*) as H FROM [dbo].[Ky_Style] SET STATISTICS TIME OFF (1 行受影响) SQL Server 执行时间: CPU 时间 = 687 毫秒，占用时间 = 925 毫秒。 (1 行受影响) SQL Server 执行时间: CPU 时间 = 594 毫秒，占用时间 = 594 毫秒。 (1 行受影响) SQL Server 执行时间: CPU 时间 = 594 毫秒，占用时间 = 688 毫秒。 1.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 不太准确，在sql server 2008测试过，不等于也可以走索引查找的，主要取决于返回的列是不是索引键，以及返回的行数在表中总行数的比率； 3.应尽量避免在 where 子句中对字段进行 null 值判断

最近连续几天，mysql数据库会运行中假死，记录一下排查过程。 1、在数据库相应缓慢的时候，用client连接上去，执行show processlist 命令， 查看是哪条语句执行缓慢，或者哪些语句执行缓慢。查询结果会列出当前正在执行哪些语句，以及执行了多长时间，当前执行状态等信息。 2、检查缓慢语句设计的表和字段，判断是否表数据量过大，或者查询条件的字段需要加索引。 3、检查是否有存储过程或者函数设计到DDL语句，DDL操作会产生metadatalock，建议业务低峰期操作。 基本上按照上面三条检查排除能解决一大部分的常见问题了。 比如，我们这次是由于日志log表数据量过大，超过800W了。导致很多数据统计相关联查询语句执行缓慢，按照惯例是需要半年把历史数据迁移到历史库去，避免经常查询的表数据过大。 来源： oschina 链接： https://my.oschina.net/u/2328100/blog/1609437