大约sql声明优化

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
日志服务 SLS,月写入数据量 50GB 1个月
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

最近做的mysql数据库优化,并sql声明优化指南。我写了一个小文件。这种互相鼓励有关!

数据库参数获得的性能优化升级都在一起只占数据库应用系统的性能改进40%左右。其余60%的系统性能提升所有来自相应用程序的优化。很多优化专家甚至觉得相应用程序的优化能够得到80%的系统性能提升。因此能够肯定。通过优化应用程序来对数据库系统进行优化能获得更大的收益。

通常可分为两个方面: SQL语句的优化和数据库性能调优。

应用程序对数据库的操作终于要表现为SQL语句对数据库的操作。而数据库性能调优是结合硬件,软件,数据量等的一个综合解决方式,这个须要測试人员进行性能測试。和开发者配合进行性能调优。

SQL语句优化

3.1关键词优化

全部关键词都大写。如:SELECT,FORM,WHERE,AND,CREATE,TABLE等等,比如:使用mysql管理工具导出sql文件,我们能够看到大部分关键词都是大写。例如以下图:

解释:这是由于,sql的处理底层。默认就将全部的sql语句,进行大写转换。

3.2 sql语句中不能存在*

在所有的查询sql语句中。不能存在*符号。

即,SELECT *FORM 

举例我们的部门表的查询。错误写法:SELECT * FROM tdepartment 正确写法:SELECT idepartmentid,scompanycode,sdepartmentname,iparentdepartmentid,sdeptposttype,sifdeleted,sleafnode,sdesc FROM tdepartment。原因:*号会检索所有字段,

*号效率低,就相当于for循环和foreach一样。用*号。sql语句查询底层会默认去字      

典库里查询公有多少个字段,然后在一个一个的取。

假设不使用*,就不是去先查字典库。

3.3 COUNT(*)使用

项目中不能使用COUNT(*)sql语句。

COUNT(*)所有替换成COUNT(1)。这在数据量比較小的情况下,不明显。可是在表中数据较多的情况下,效果很明显。

3.4多用匹配查询,少用like查询

      原因,like查询会直接放弃索引。

3.5主键索引使用

      全部表的主键全是索引。应尽量使用主键查询。如:SELECT * FROM tusers ORDER BY dregistertime DESC效率低于SELECT * FROM tusers ORDER BY iuserid DESC。这是由于全部的主键都默认是索引。

而注冊时间不是索引字段。 

3.6第12索引排列使用

如果我们的用户表中的scompanycode,dregistertime两个字段都创建了索引。而scompanycode是第一索引。dregistertime是第二索引。

那么查询时:SELECT * FROM tusers ORDER BY scompanycode,dregistertime DESC的效率高于SELECT * FROM tusers ORDER BY dregistertime,scompanycode DESC。这是由于第一索引将首先被检索。

3.7建表不要给字段设置默认值

如:`sifaudited` varchar(2) default '0' COMMENT '0:未审核。1:已审核'。默认值会在插入数据时,添加数据库底层推断是否有值情况,进行赋默认值。

3.8字段不要留null

这是由于null值占用的数据大小比較大。

Null和空一般占48个字节。如:`scompanycode` varchar(16) default NULL COMMENT '公司编号(唯一识别)',对于这种,我们一般把空值改为0,你们应该懂的。

3.9多用子查询

      子查询性能高于连接查询。

子查询性能高于左联接、右连接、全连接查询。

3.10连接查询性能高于循环查询

对于部门查询。我们通常是查询根文件夹,然后循环查询子部门。一直循环到查询结束。性能较低。

我们应该採用,连接查询。

或者写函数,存储过程进行查询。

4.设计优化

4.1 日志模块。新增队列。当日志达到100条或者200500条的时候,我们採用批量插入n条,降低磁盘的io次数。这样能够延长磁盘的寿命,同一时候对数据的插入也有了明显的提高。

5.数据库引擎使用

5.1   ENGINE = innodb

    Innodb数据库引擎是对外键。事务进行过优化。

我们对创建全部的表都使用innodb引擎。这是错误的,应该对每个表的用途相应一个不同的数据库引擎。

5.2   ENGINE = MyISAM

MyISAM类型不支持事务处理等高级处理。

MyISAM类型的表强调的是性能,其运行数度比InnoDB类型更快,可是不提供事务支持。

MyISAM类型的二进制数据文件能够在不同操作系统中迁移。也就是能够直接从Windows系统复制到linux系统中使用。

这个是默认类型,它是基于传统的ISAM类型,ISAMIndexed Sequential Access Method (有索引的 顺序訪问方法的缩写,它是存储记录和文件的标准方法.与其它存储引擎比較,MyISAM具有检查和修复表格的大多数工具. MyISAM表格能够被压缩,并且它们支持全文搜索.它们不是事务安全的,并且也不支持外键。假设事物回滚将造成不全然回滚,不具有原子性。

假设运行大量 的SELECTMyISAM是更好的选择。这个类型东海们项目使用的多。最经常使用的引擎之中的一个。

5.3   ENGINE = BDB

BDB:可替代InnoDB的事务引擎,支持COMMITROLLBACK和其它事务特性。

5.4   ENGINE = Memory

Memory:将全部数据保存在RAM中,在须要高速查找引用和其它类似数据的环境下,可提供极快的訪问。

5.5   ENGINE = Merge

Merge:同意MySQL DBA或开发者将一系列等同的MyISAM表以逻辑方式组合在一起,并作为1个对象引用它们。

对于诸如数据仓储等VLDB环境十分适合。

5.6    ENGINE = Archive

Archive:为大量非常少引用的历史、归档、或安全审计信息的存储和检索提供了完美的解决方式。

5.7    ENGINE = Federated

 Federated:可以将多个分离的MySQLserver链接起来,从多个物理server创建一个逻辑数据库。十分适合于分布式 环境或数据集市环境。

5.8    ENGINE =Cluster/NDB

Cluster/NDBMySQL的簇式数据库引擎,尤其适合于具有高性能查找要求的应用程序,这类查找需求还要求具有最高的正常工作时间和可用性

5.9    Other:其它存储引擎包含CSV(引用由逗号隔开的用作数据库表的文件)。Blackhole(用于暂时禁止对数据库的应用程序输入)。以及Example引擎(可为高速创建定制的插件式存储引擎提供帮助)。

6.表字段设计

  6.1对于类型限制。是否删除字段。如:`sifdeleted` varchar(2) default '0' COMMENT '0:正常;1:已删除',使用int(1)类型标识。不要使用varchar(2)多占用空间。

     6.2 对于字段长度限制,如手机号11位。我们就没有必要设计很多其它位数。公司编号能够仅仅设定8位。username限制32位等等。

     6.3 少用外键限制

         我们能够使用代码限制。

如:级联删除,级联新增,改动等等操作。

最好不要设计外键,外键对新增数据不利。

     6.4  少用约束,如:唯一约束。

 6.5  少用自己主动增长

      在圆通主键没有自己主动增长,而是使用uuidjava自己主动生成。考虑到我们数据表数据较少,少用。

 6.6  对于内容较少的表,没有必要创建索引。由于索引浪费空间。

 6.7  表分区使用

      对于日志表,我们能够使用表分区。表分区之后。对于查询效率有非常高的提升。默认有时间分区。大小分区。类型分区等等。

 6.8  对表的内容进行限制。如:日志表能够限制条数。

再创建表时。我们使用MAX_ROWS进行限制。

7.其它请遵守建表规则

   如:三范式等。

好吧就到这里,欢迎大家关注我的个人博客!

如有疑问,请加qq群:135430763 共同学习!


点击下载文档:

版权声明:本文博客原创文章。博客,未经同意,不得转载。





本文转自mfrbuaa博客园博客,原文链接:http://www.cnblogs.com/mfrbuaa/p/4656478.html,如需转载请自行联系原作者


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
相关文章
|
1月前
|
SQL 存储 监控
SQL日志优化策略:提升数据库日志记录效率
通过以上方法结合起来运行调整方案, 可以显著地提升SQL环境下面向各种搜索引擎服务平台所需要满足标准条件下之数据库登记作业流程综合表现; 同时还能确保系统稳健运行并满越用户体验预期目标.
180 6
|
9月前
|
SQL 关系型数据库 MySQL
MySQL进阶突击系列(07) 她气鼓鼓递来一条SQL | 怎么看执行计划、SQL怎么优化?
在日常研发工作当中,系统性能优化,从大的方面来看主要涉及基础平台优化、业务系统性能优化、数据库优化。面对数据库优化,除了DBA在集群性能、服务器调优需要投入精力,我们研发需要负责业务SQL执行优化。当业务数据量达到一定规模后,SQL执行效率可能就会出现瓶颈,影响系统业务响应。掌握如何判断SQL执行慢、以及如何分析SQL执行计划、优化SQL的技能,在工作中解决SQL性能问题显得非常关键。
|
6月前
|
SQL 存储 自然语言处理
SQL的解析和优化的原理:一条sql 执行过程是什么?
SQL的解析和优化的原理:一条sql 执行过程是什么?
SQL的解析和优化的原理:一条sql 执行过程是什么?
|
8月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
9月前
|
SQL 关系型数据库 MySQL
基于SQL Server / MySQL进行百万条数据过滤优化方案
对百万级别数据进行高效过滤查询,需要综合使用索引、查询优化、表分区、统计信息和视图等技术手段。通过合理的数据库设计和查询优化,可以显著提升查询性能,确保系统的高效稳定运行。
425 9
|
10月前
|
SQL Oracle 关系型数据库
如何在 Oracle 中配置和使用 SQL Profiles 来优化查询性能?
在 Oracle 数据库中,SQL Profiles 是优化查询性能的工具,通过提供额外统计信息帮助生成更有效的执行计划。配置和使用步骤包括:1. 启用自动 SQL 调优;2. 手动创建 SQL Profile,涉及收集、执行调优任务、查看报告及应用建议;3. 验证效果;4. 使用 `DBA_SQL_PROFILES` 视图管理 Profile。
|
11月前
|
SQL Oracle 数据库
使用访问指导(SQL Access Advisor)优化数据库业务负载
本文介绍了Oracle的SQL访问指导(SQL Access Advisor)的应用场景及其使用方法。访问指导通过分析给定的工作负载,提供索引、物化视图和分区等方面的优化建议,帮助DBA提升数据库性能。具体步骤包括创建访问指导任务、创建工作负载、连接工作负载至访问指导、设置任务参数、运行访问指导、查看和应用优化建议。访问指导不仅针对单条SQL语句,还能综合考虑多条SQL语句的优化效果,为DBA提供全面的决策支持。
277 11
|
SQL 缓存 监控
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
本文详细解析了数据库、缓存、异步处理和Web性能优化四大策略,系统性能优化必知必备,大厂面试高频。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
|
10月前
|
SQL 分布式计算 Java
Spark SQL向量化执行引擎框架Gluten-Velox在AArch64使能和优化
本文摘自 Arm China的工程师顾煜祺关于“在 Arm 平台上使用 Native 算子库加速 Spark”的分享,主要内容包括以下四个部分: 1.技术背景 2.算子库构成 3.算子操作优化 4.未来工作
1336 0
|
12月前
|
SQL 缓存 数据库
SQL慢查询优化策略
在数据库管理和应用开发中,SQL查询的性能优化至关重要。慢查询优化不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将详细介绍针对SQL慢查询的优化策略。