InnoDB

mysql： --查询慢sql：业务db用户 select b.time, b.host, b.id, b.state, b.user, b.db, b.info from information_schema.processlist b where b.info is not null order by b.time 1、查询是否锁表 show OPEN TABLES where In_use > 0; 2、查询进程 show processlist 查询到相对应的进程===然后 kill pid 补充： 查看正在锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS; 查看等待锁的事务 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 计算ID select (1000+500+500+500+500+500+500+260+280)-4641.33 from dual; --------------------- 监控慢SQL SELECT G.TARGET || ' ' || S.MACHINE || ' ' || ceil((G.LAST_UPDATE_TIME - G.START_TIME)*86400) FROM V$SESSION_LONGOPS G, V

做后台开发的程序猿通常需要写各种各样的sql，可很多时候写出来的sql虽然能满足功能性需求，性能上却不尽人意。如果业务复杂，表结构和索引设计又不合理的话，写出来的sql执行时间可能会达到几十甚至上百秒，对于生产环境来说，这是相当恐怖的一件事。因此，了解一些常见的mysql优化技巧很有必要。本文将从表结构和索引设计，sql执行原理，sql编写优化3方面进行分析和讲解，希望能对大家有所帮助。 1、表结构，字段设计是否合理？ 这是最基础也是最容易忽视的一个环节。良好的表结构设计是sql优化的基础，在这个存储廉价，空间足够的时代，设计表的过程中，不一定要完全满足范式理论，我们可以通过适当的冗余设计，避免连表查询，达到以空间来换取时间的目的。设计表的时候，我们会根据业务需求来决定建几个表，表之间通过哪些外键来关联。而且通常需要考虑到数据规模（单表记录数最好不要超过千万，如果超过可能需要分表分区，包括垂直分表和水平分表）、查询更新频率（哪些字段经常用于查询，哪些经常用于更新），各字段的类型和长度取值，在哪些字段上建哪种类型的索引等等。 比方说，如果你是innodb存储引擎，那么你的主键最好设计成自增的，这样效率最高。因为innodb存储引擎的索引是基于B+树实现，如果采用自增设计，就能快速找到插入节点的位置进行插入或删除，对其他节点影响较小，避免频繁分裂树结构

https://blog.csdn.net/mu_wind/article/details/110128016 前言 相信每个IT界大佬，简历上少不了Mysql索引这个关键字，但如果被问起来，你能说出多少干货呢？先看下面几个问题测试一下吧： 索引是怎么提高查询效率的？可以为了提高查询效率增加索引么？ mysql索引系统采用的数据结构是什么？ 为什么要使用B+树？ 聚集索引相对于非聚集索引的区别？ 什么是回表？ 什么是索引覆盖？ 什么是最左匹配原则？ 索引失效场景有哪些，如何避免？ 这些问题说不明白？不要慌！请带着问题向下看。 1 索引原理探究 什么是数据库索引？先来个官方一些的定义吧。 在关系数据库中，索引是一种单独的、物理的数对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单。 这段话有点绕，其实把索引理解为图书目录，就非常好理解了。 如果我们想在图书中查找特定内容，在没有目录的情况下只能逐页翻找。与此类似，当执行下面这样一条SQL语句时，假如没有索引，数据库如何查找到相对应的记录呢？ SELECT * FROM student WHERE name = '叶良辰' 搜索引擎只能扫描整个表的每一行，并依次对比判断 name 的值是否等于“叶良辰”。我们知道，单纯的内存运算是很快的

在MySQL的慢查询日志中出现只有commit，但是没有任何其它SQL的这种现象到底是一个什么情况呢？如下截图所示（没有优化前的一个Zabbix数据库） 其实在慢查询日志中出现commit，就是因为事务提交（commit）的时间过长。至于为什么commit的时间过长，可能有下面一些原因： 1：磁盘IO过载时或者发生故障的时候，因此在事务完成时进行刷新（flush）需要很长时间。 2：二进制日志轮换（ Rotate ）时，在二进制日志轮换完成之前，无法提交其他任何事务。这个会引起事务提交出现短暂的停顿/卡顿。尤其当二进制日志过大或者IO性能差的时候，这个停顿可能更长。导致commit的时间超过参数 long_query_time 的值。从而 commit 语句出现在慢查询日志。 3: MySQL的系统参数innodb_flush_log_at_trx_commit、sync_binlog、max_binlog_size的设置可能会引起这种现象。但是注意，并不是说设这些参数的某个设置就一定会引起这个现象。而是说在某种取值下，在磁盘IO过载，业务暴增等一系列的综合因素影响下，会增加这种现象出现的概率。 举个例子，将MySQL配置为sync_binlog = 0的情况下，这可能导致操作系统缓存整个二进制日志，甚至使用最快的磁盘。默认情况下，最大二进制日志大小为1G，如果所有日志均已缓存

作者： 一枝花算不算浪漫 [1] 原文地址：https://www.cnblogs.com/wang-meng/p/ae6d1c4a7b553e9a5c8f46b67fb3e3aa.html 小结： 回表 ：回到主键索引树搜索的过程，我们称为回表。 覆盖索引 ：就是 select 的数据列只用从索引中就能够取得，不必从数据表中读取。简单点说就是你要查的数据索引里都有，一次搞定，美滋滋 😎。 延迟关联 ：通过使用覆盖索引查询返回需要的主键，再根据主键关联原表获得需要的数据。 1. 前言 上周新系统改版上线，上线第二天就出现了较多的线上 慢 sql 查询，紧接着 dba 给出了定位及解决方案，这里较多的是使用 延迟关联 去优化。 而我对于这个 延迟关联 也是第一次听说（o(╥﹏╥)o），所以今天一定要学习并产出一篇学习笔记。( ^▽^ ) 2. 回表 我们都知道 InnoDB 采用的 B+ tree 来实现索引的，索引又分为主键索引(聚簇索引)和普通索引(二级索引)。 那么我们就来看下 基于主键索引和普通索引的查询有什么区别？ 如果语句是 select * from T where ID=500，即主键查询方式，则只需要搜索 ID 这棵 B+树； 如果语句是 select * from T where k=5，即普通索引查询方式，则需要先搜索 k 索引树，得到 ID 的值为 500

回顾： ACID ：DBMS在写入或更新资料的过程中，为保证事务正确可靠，具有的四个特性：原子性（不可分割性）、一致性、隔离性（独立性）、持久性 一个事务 ：一系列数据库操作组成的一个完整的逻辑过程 原子性 ：一个事务中的所有操作，要么全部完成、要么全部不完成，若发生错误，回滚（RollBack) 一致性 :事务开始之前和事务结束之后，数据库的完整性没有破坏 隔离性 ：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不 同级别 ：读未提交、读提交、可重复读、串行化 持久性 ：事务处理结束后，对数据的修改时永久性的，系统出故障也不会改变 锁 ：协调多个进程或线程并发访问某一资源的一种机制.锁冲突是影响数据库并发访问性能的重要因素。 存储引擎支持不同的锁机制 行锁 表锁 页锁 MyISAM 支持 BDB 支持 支持 InnoDB 支持 支持 开销、加锁速度、死锁、粒度、并发性能 行锁 ：开销大，加锁慢，会出现死锁；锁定粒度小，锁冲突概率小，并发度高 表锁 ：开销小，加锁快，不会出现死锁；锁定粒度大，发生锁冲突概率高，并发度最低 页锁 ：开销和加锁速度介于行锁和表锁之间，会出现死锁；锁粒度介于表锁和行锁之间，并发度一般 ###根据具体应用决定适合那种锁，仅从锁的角度：表锁适合以查询为主

作为一名后端开发，MySQL的使用必不可少，合理的使用索引和索引调优是后端开发者必须掌握的技能之一。 在日常数据库的问题当中，不合理的使用索引占大部分。 MySQL是大家工作上最常用的关系型数据库之一，也是面试上必问的知识点。 我们在学会建库、创表等基本操作之后就停止了对MySQL的整个深度的学习与专研。 但随着互联网业务的快速发展。 对于数据库的高并发，高可用等指标的要求也越来越高，所以这个时候，底层的机制、原理慢慢地被人们所重视。 故而很多的一线互联网公司对于数据库的机制原理是面试必问的内容。 比如你去面试时，面试官问你： 1、索引的本质是什么？ 2、三星索引有了解吗？ 你是如何理解的？ 3、Innodb引擎如何保证事务的并发处理的？ 4、你们公司SQL的执行最长的时间是多少秒？ 有分析过原因吗？ 解决的思路是怎样的？ 等等~ 这时你会一脸懵逼，被面试官虐惨。 以上的几个问题还没有完全正确的回答出来的小伙伴们可要反省反省了，毕竟这是目前一线互联网面试必问的知识点啊！ MySQL有这么重要？，难学么？我个人认为，MySQL掌握以下知识内容即可突破瓶颈 1、掌握MySQL的整体体系结构，了解MySQL特色的各大存储引擎的特点。 2、深入MySQL的索引机制，做到每一个SQL执行能在脑海中构建数据搜索的过程。 3、理解MySQL中一条SQL语句的执行路径及每个环节的重要意义。

本文对 MySQL Server Variable: sync_binlog (Doc ID 1501926.1) 这篇文章进行了翻译，如有翻译不当或错误的地方敬请指正。 译文地址： https://www.cnblogs.com/kerrycode/p/14167941.html In this Document Purpose Scope Details Performance Impact of sync_binlog Recommendation References APPLIES TO: MySQL Server - Version 4.1 to 5.6 [Release 4.1 to 5.6] Information in this document applies to any platform. PURPOSE Explain when and why to use the sync_binlog setting in MySQL Server. 解释在 MySQL Server 中什么时候设置参数 sync_binglog 以及为什么要设置参数 sync_binglog SCOPE Detailed general guidance for DBAs who are familiar with the option and looking for help on

一.对待存储过程和函数的态度 优点： 1.存储过程只在创建时进行编译，sql语句则每次执行都需要编译。能提高数据库执行速度。 2.简单复杂操作结合事物一起封装。 3.复用性高。 4.安全性高，可指定存储过程的使用权。 在 实际项目中应该尽量少用存储过程和函数 ，理由如下： 1. 移植性差 ，在MySQL中的存储过程移植到sqlsever上就不一定可以用了。 2. 调试麻烦 ，在db中报一个错误和在应用层报一个错误不是一个概念，那将是毁灭性打击，直接一个error：1045什么的更本毫无头绪。 3. 扩展性不高 。 所以在互联网时代大型项目应该尽量少使用（不使用）存储过程和函数。 二.创建存储过程 2.1什么是存储过程？ 存储过程和存储函数都是一组sql语句的集合。这些语句集合被当做一个整体存入数据库中。 2.2创建存储过程的语法： create procedure 存储过程名(参数列表) sql语句 例子： delimiter // create procedure pro() reads sql data begin select * from stu; end 那么我们现在就有一个存储过程pro了，但是这个存储过程他是没有参数的，他只是执行一次查询操作。 我们现在来讲解一下这个存储过程的结构： delimiter // 是将分号转化为// 因为在sql执行时当他遇到分号 ；