sql优化

MySQL之IN的优化

眉间皱痕 提交于 2020-01-19 06:10:47
场景描述: MySQL的IN的问题:由于in里面的内容过于庞大 (5000+),导致查询效率低下(4秒以上)。 SELECT * FROM xxx WHERE ` id ` IN ( xxx ) 计划解决方案: 1.测试得到IN里面的最佳数量 2.循环分多次查询 3.多线程共同执行 实际测试记录: 1.查询最佳数量 1次 4265ms、4177ms、4112ms 平均4.18秒 5643条 2次 1128ms、1105ms、1117ms 平均2.23秒 2822条 3次 326ms、298ms、326ms 平均1.27秒 1411条 8次 117ms、91ms、88ms、100ms、86ms 平均0.77秒 705条 20次 43 32 24 25 34 23 24 27 28 22 平均0.56秒 282条 40次 25 16 11 10 13 10 10 10 13 10 平均0.51秒 141条 30次 29 18 17 13 14 15 15 17 15 17 平均0.51秒 188条 结论: 20次和40次差距不大,又测试了30次的数据结果,结果和40次一样。 mysql查询次数对性能也有影响,所以我们以200条定为最佳数量值进行测试. 2.循环查询 (29次) Integer total = orderIds . size ( ) ; Integer size =

SQL 创建索引的目的是什么?

可紊 提交于 2020-01-19 03:34:21
一、 SQL 创建索引的目的如下: 1 、通过唯一性索引(unique)可确保数据的唯一性; 2 、加快数据的检索速度; 3 、加快表之间的连接; 4 、减少分组和排序时间; 5 、使用优化隐藏器提高系统性能。 二、创建 SQL 索引的语法: CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] (索引类型) INDEX < 索引名 > ON < 表名 > ( < 列名 > [ ASC | DESC ] [ , < 列名 > [ ASC | DESC ] ... ] ) 。 扩展资料: 索引的类别介绍: 1 、唯一索引: 唯一索引是不允许其中任何两行具有相同索引值的索引。当现有数据中存在重复的键值时,大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。 2 、主键索引: 数据库表经常有一列或多列组合,其值唯一标识表中的每一行。该列称为表的主键。在数据库关系图中为表定义主键将自动创建主键索引,主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时,它还允许对数据的快速访问。 来源: CSDN 作者: 我冷漠 链接: https://blog.csdn.net/weixin_43748615/article/details/103910654

SQL Server 数据库性能优化

不想你离开。 提交于 2020-01-19 03:23:02
1. 查看执行时间和cpu set statistics time on select * from Bus_DevHistoryData set statistics time off 执行后在消息里可以看到 2. 查看查询对I/O的操作情况 set statistics io on select * from Bus_DevHistoryData set statistics io off 执行之后的结果: 扫描计数:索引和表执行次数 逻辑读取:数据缓存中读取的页数 物理读取:从磁盘中读取的页数 预读:查询过程中,从磁盘放入缓存的页数 lob逻辑读取:从数据缓存中读取image、text、ntext或大型数据的页数 lob物理读取:从磁盘中读取image、text、ntext或大型数据的页数 lob预读:查询过程中,从磁盘放入缓存的image、text、ntext或大型数据的页数 如果物理读取次数和预计次数比较多,可以使用索引进行优化。 上述两种信息的查看如果不想写sql,可以通过设置完成: 工具->选项 3. 查看执行计划 选中查询语句,点击 一、数据库设计优化 1、不要使用游标。 使用游标不仅占用内存,而且还用不可思议的方式锁定表,它们可以使DBA所能做的一切性能优化等于没做。游标里每执行一次fetch就等于执行一次select。 2、创建适当的索引

mysql参数优化

余生颓废 提交于 2020-01-18 19:03:02
### 用来存放InnoDB的内部目录,对于大数据设置16M足够用 innodb_additional_mem_pool_size = 16M ### InnoDB 缓存总大小设置,一般设置为系统内存的70%-80% innodb_buffer_pool_size = 12G ### 指定所有InnoDB数据文件的路径和大小分配 innodb_data_file_path = ibdata1:18M;ibdata2:1000M:autoextend ### 文件读写io数设置: innodb_file_io_threads = 4 ### InnoDB内核的并发线程数设置 innodb_thread_concurrency = 16 ### 设置日值的大小 innodb_log_file_size = 256M ### 设置日值组个数 innodb_log_files_in_group = 3 ### 事物在内存中的缓存大小 innodb_log_buffer_size = 8M ### 控制事物的提交方式,设置为2性能上最快 innodb_flush_logs_at_trx_commit = 2 ### InnoDB直接写入磁盘设置,避免重复缓冲和减少linux交换分区的压力 innodb_flush_method = O_DIRECT ###

mysql间隙锁

百般思念 提交于 2020-01-18 17:43:32
什么是间隙锁(gap lock)?   间隙锁是一个在索引记录之间的间隙上的锁。 间隙锁的作用?     保证某个间隙内的数据在锁定情况下不会发生任何变化。比如我mysql默认隔离级别下的可重复读(RR)。    当使用唯一索引来搜索唯一行的语句时,不需要间隙锁定 。如下面语句的id列有唯一索引,此时只会对id值为10的行使用记录锁。     select * from t where id = 10 for update;// 注意:普通查询是快照读,不需要加锁   如果,上面语句中id列没有建立索引或者是非唯一索引时,则语句会产生间隙锁。   如果,搜索条件里有多个查询条件(即使每个列都有唯一索引),也是会有间隙锁的。   需要注意的是,当id列上没有索引时,SQL会走聚簇索引的全表扫描进行过滤,由于过滤是在MySQL Server层面进行的。因此每条记录(无论是否满足条件)都会被加上X锁。但是,为了效率考量,MySQL做了优化,对于不满足条件的记录,会在判断后放    锁,最终持有的,是满足条件的记录上的锁。但是不满足条件的记录上的加锁/放锁动作是不会省略的。所以在没有索引时,不满足条件的数据行会有加锁又放锁的耗时过程。 间隙的范围?   根据检索条件向下寻找最靠近检索条件的记录值A作为左区间,向上寻找最靠近检索条件的记录值B作为右区间,即锁定的间隙为(A,B] 左开右闭 。

mysql order by limit 使用注意事项

百般思念 提交于 2020-01-18 12:23:36
5.7以上重复数据问题 order by limit会出现数据重复问题 --查看mysql版本 select version() --创建表 create table student( id int(10) PRIMARY KEY auto_increment, name varchar(32), age int(3) ) --插入数据 insert into student VALUEs(null,'小明',11); insert into student VALUEs(null,'王小明',5); insert into student VALUEs(null,'小二毛',11); insert into student VALUEs(null,'王小三',4); insert into student VALUEs(null,'毛小二',11); insert into student VALUEs(null,'张小二',11); --插入表 select * from student s order by age desc --分页查询 select * from(select * from student s order by age desc LIMIT 0,1)tab union all select * from(select * from student s

数据库访问性能优化

帅比萌擦擦* 提交于 2020-01-18 09:23:35
特别说明: 1、 本文只是面对数据库应用开发的程序员,不适合专业 DBA , DBA 在数据库性能优化方面需要了解更多的知识; 2、 本文许多示例及概念是基于 Oracle 数据库描述,对于其它关系型数据库也可以参考,但许多观点不适合于 KV 数据库或内存数据库或者是基于 SSD 技术的数据库; 3、 本文未深入数据库优化中最核心的执行计划分析技术。 读者对像: 开发人员: 如果你是做数据库开发,那本文的内容非常适合,因为本文是从程序员的角度来谈数据库性能优化。 架构师: 如果你已经是数据库应用的架构师,那本文的知识你应该清楚 90% ,否则你可能是一个喜欢折腾的架构师。 DBA (数据库管理员): 大型数据库优化的知识非常复杂,本文只是从程序员的角度来谈性能优化, DBA 除了需要了解这些知识外,还需要深入数据库的内部体系架构来解决问题。 引言 在网上有很多文章介绍数据库优化知识,但是大部份文章只是对某个一个方面进行说明,而对于我们程序员来说这种介绍并不能很好的掌握优化知识,因为很多介绍只是对一些特定的场景优化的,所以反而有时会产生误导或让程序员感觉不明白其中的奥妙而对数据库优化感觉很神秘。 很多程序员总是问如何学习数据库优化,有没有好的教材之类的问题。在书店也看到了许多数据库优化的专业书籍,但是感觉更多是面向 DBA 或者是 PL/SQL 开发方面的知识

MySQL 核心技术_存储引擎

淺唱寂寞╮ 提交于 2020-01-18 04:58:10
存储引擎 1. 存储引擎介绍 相当于Linux 文件系统.组织存储表数据. 2. 存储引擎的种类 show engines; InnoDB MyISAM CSV Memory 其他的存储引擎: MariaDB : InnoDB,TokuDB ,Myrocks percona : xtradb ,TokuDB ,Myrocks TokuDB ,Myrocks : 比较适合于在写入操作较多的场景,数据量级大的场景. 原因是: 插入性能很高, 压缩比较高. 监控类的业务. 学员案例: 环境: zabbix 3.x mariaDB 5.5 centos 7.3 现象 : zabbix卡的要死 , 每隔3-4个月,都要重新搭建一遍zabbix,存储空间经常爆满. 问题 :zabbix 版本 数据库版本 —> 5.5 ----> ibdata1 ----> 5.7 ,8.0 zabbix数据库500G,存在一个文件里 优化建议: 1.数据库版本升级到Mairia 10.x版本,zabbix升级更高版本 2.存储引擎改为tokudb 3.监控数据按月份进行切割(二次开发:zabbix 数据保留机制功能重写,数据库分表) 4.关闭binlog和双1 等安全参数需要关闭 5.参数调整… 优化结果: 监控状态良好 select concat(“alter table zabbix.”,table

MySQL事务的实现原理

[亡魂溺海] 提交于 2020-01-17 21:38:58
特点 原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability) 一、事务的目的 1、可靠性和并发处理 可靠性:数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致,想要做到这个,我需要知道我修改之前和修改之后的状态,所以就有了undo log和redo log。 并发处理:也就是说当多个并发请求过来,并且其中有一个请求是对数据修改操作的时候会有影响,为了避免读到脏数据,所以需要对事务之间的读写进行隔离,至于隔离到啥程度得看业务系统的场景了,实现这个就得用MySQL 的隔离级别。 二、实现事务功能的三个技术 1、日志文件(redo log 和 undo log) 2、锁技术 3、MVCC 1.1 redo log 与 undo log介绍 1.1.1redo log 什么是redo log ? redo log叫做重做日志,是用来实现事务的持久性。该日志文件由两部分组成:重做日志缓冲(redo log buffer)以及重做日志文件(redo log),前者是在内存中,后者在磁盘中。 当事务提交之后会把所有修改信息都会存到该日志中。假设有个表叫做tb1(id,username) 现在要插入数据(3,ceshi) start transaction; select

PL/SQL性能优化

ⅰ亾dé卋堺 提交于 2020-01-17 21:31:43
一:SQL性能优化原理 1.1sql处理体系结构 1.2执行计划 sql语句转换前的步骤: 1.语法检查:检查sql语句的拼写是否正确 2.语义分析:核实所有与数据字典不一致的表或列的名字 3.概要存储检查:检查数据字典,以确定该sql语句的概要信息是否已经存在 4.生产执行计划:使用CBO规则和数据字典中的统计表来决定最佳执行计划 5.生成二进制代码:基于执行计划,生成可执行代码 执行计划是oracle在执行每个sql语句时所采取的执行顺序. 执行计划包括: 1.语句所引用的表的顺序 2.语句所设计的表的访问方式 3.语句中连续操作所影响到的各表的连接方法 查看计划前授权: --系统用户执行 SQL > @D :\Oracle\app\oracle\product\ 10.2 .0 \server\RDBMS\ADMIN\utlxplan . sql ; --本地电脑路径,执行utlxplan.sql Table created Executed in 0.047 seconds SQL > grant plustrace to scott ; --授权 Grant succeeded Executed in 0.009 seconds --scott用户 SQL > @D :\Oracle\app\oracle\product\ 10.2 .0 \server\RDBMS