5.合理创建联合索引（避免冗余），(a,b,c) 相当于 (a) 、(a,b) 、(a,b,c)
索引是对数据库表中一个或多个列（例如，employee 表的姓名 (name) 列）的值进行排序的结构。 例如这样一个查询：select * from table1 where id=10000 如果没有索引，必须遍历整个表，直到ID等于10000的这一行被找到为止；有了索引之后(必须是在ID这一列上建立的索引)，即可在索引中查找。由于索引是经过某种算法(B+ 树)优化过的，因而查找次数要少的多。可见，索引是用来定位的。
数据库性能优化 01 MySQL 性能优化 表的设计合理化，符合三大范式（3NF) 1NF是对属性的原子性约束，要求属性(列)具有原子性，不可再分解；(只要是关系型数据库都满足1NF) 2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； 3NF是对字段冗余性的约束，它要求字段没有冗余。 没有冗余的数据库设计可以做到。 添加适当索引(index) [四种: 普通索引、主键索引、唯一索引unique、全文索引] 较频繁的作为查询条件字段应该创建索引； 唯一性太差的字段不适合单独创建索引，即使
提起索引大家都不陌生，但在mysql中也有不使用索引的情况，接下来我们一起看看都有哪些不走索引的sql语句。
本文的宗旨在于通过简单干净实践的方式，向读者展示 SpringBoot 应用程序对接 MySQL 时，在使用不同连接池以及不使用连接池时，在增删改查的一个性能对比。这也包括更新和查询时，索引字段的关键性。
最近涉及数据库相关操作较多，公司现有规范也不是太全面，就根据网上各路大神的相关规范，整理了一些自用的规范用法，万望指正。
数据库环境 dev：开发环境，开发可读写，可修改表结构。开发人员可以修改表结构，可以随意修改其中的数据但是需要保证不影响其他开发同事。 qa：测试环境，开发可读写，开发人员可以通过工具修改表结构。 sim：模拟环境，开发可读写，发起上线请求时，会先在这个环境上进行预执行，这个环境也可供部署上线演练或压力测试使用。 real：生产数据库从库（准实时同步），只读环境，不允许修改数据，不允许修改表结构，供线上问题查找，数据查询等使用。 online：线上环境，开发人员不允许直接在线上环境进行数据库操作，如果需要操
①普通索引：这是最基本的索引类型，而且它没有唯一性之类的限制。普通索引可以通过以下几种方式创建：
一、简介 最近在压测新的存储，正好把工作过程中积累的对高性能MySQL相关的知识体系构建起来，做成思维导图的方式。总结乃一家之言，有不妥之处，望给位读者朋友指正。 二、思维导图 构建高性能MyS
一.索引的作用 一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，所以查询语句的优化显然是重中之重。 在数据量和访问量不大的情况下，mysql访问是非常快的，是否加索引对访问影响不大。但是当数据量和访问量剧增的时候，就会发现mysql变慢，甚至down掉，这就必须要考虑优化sql了，给数据库建立正确合理的索引，是mysql优化的一个重要手段。 索引的目的在于提高查询效率，
InnoDB支持的哈希索引是自适应的，InnoDB会根据表的使用情况自动为表生成哈希索引，不能人为干预在表中生产哈希索引
上周在公司做了针对MySQL 8.0新特性相关的分享，提到MySQL 8.0新特性，不得不提到的就是HashJoin，MySQL一直被人诟病没有实现HashJoin，从8.0.18已经带上了这个功能，令人欣喜。有时候在想，MySQL为什么一直不支持HashJoin呢？可能是因为MySQL多用于简单的OLTP场景，并且在互联网应用居多，需求没那么紧急。另一方面在8.0.18之前，MySQL只支持Nest Loop Join算法，MySQL针对这个算法做了若干优化，实现了Block NestLoop Join，Index NestLoop Join等，有了这些优化，在一定程度上能缓解对HashJoin的迫切程度。本文会介绍HashJoin的原理以及在使用和不使用HashJoin的情况下，性能的差异。
但也可能因为你使用错误的SQL语句而无法使用。其中有以下几种，在使用sql查询时尽量避免。
索引是一把双刃剑，它可以提高查询效率但也会降低插入和更新的速度并占用磁盘空间
可以使用explain命令加在要分析的sql语句前面，在执行结果中查看key这一列的值，如果为NULL，说明没有使用索引。
blog.csdn.net/weixin_39420024/article/details/80040549
索引是帮助MySQL高效获取数据的数据结构。索引是在存储引擎中实现的，所以每种存储引擎中的索引都不一样。如MYISAM和InnoDB存储引擎只支持BTree索引；MEMORY储存引擎可以支持HASH和BTREE索引。
在使用explain分析查询的时候，利用有序索引获取有序数据显示Using index。而文件排序显示Using filesort。
所谓索引就是为特定的mysql字段进行一些特定的算法排序,比如二叉树的算法和哈希算法,哈希算法是通过建立特征值,然后根据特征值来快速查找,而用的最多,并且是mysql默认的就是二叉树算法 BTREE,通过BTREE算法建立索引的字段,比如扫描20行就能得到未使用BTREE前扫描了2^20行的结果,具体的实现方式后续本博客会出一个算法专题里面会有具体的分析讨论;
MySQL索引分为普通索引、唯一索引、主键索引、组合索引、全文索引。索引不会包含有null值的列，索引项可以为null（唯一索引、组合索引等），但是只要列中有null值就不会被包含在索引中。
mysql作为最流行的数据库，在开发过程中仍然有较多优化的空间，mysql的优化主要有4个方向：
索引是帮助MySQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。
在上一篇文章《用Explain 命令分析 MySQL 的 SQL 执行》中，我们讲解了 Explain 命令的详细使用。但是它只能展示 SQL 语句的执行计划，无法展示为什么一些其他的执行计划未被选择，比如说明明有索引，但是为什么查询时未使用索引等。为此，MySQL 提供了 Optimizer Trace 功能，让我们能更加详细的了解 SQL 语句执行的所有分析，优化和选择过程。
数据库设计规范 命名规范 基本设计规范 索引设计规范 字段设计规范 SQL开发规范 操作行为规范 命名规范 对象名称使用小写字母并用下划线分割 禁止使用MySQL保留关键字 见名识义，最好不超过32个
从开篇词我们了解到，本专栏首先会一起讨论一下 SQL 优化，而优化 SQL 的前提是能定位到慢 SQL 并对其进行分析，因此在专栏的开始，会跟大家分享如何定位慢查询和如何分析 SQl 执行效率。在前面两节，会用一些简单的例子让大家学会这些分析技巧。
使用 EXPLAIN 查看执行计划， 5.6后可以加参数 EXPLAIN FORMAT=JSON xxx输出json格式的信息。
文章目录 1. Explain 1.1. id 1.1.1. id相同 1.1.2. id不同 1.2. table 2. 索引优化 2.1. 全值匹配 2.2. 最佳左前缀法则 2.3. 不在索引上列上做任何操作 2.4. 不能使用索引中范围条件右边的列（范围之后的索引全失效） 2.5. 使用覆盖索引，少使用select* 2.6. mysql在使用不等于(!=或者<>)的时候无法使用导致全表扫描 2.7. 在使用or的时候，前后两个都是索引的时候才会生效 2.8. is null和is not nu
转载自 http://blog.csdn.net/kaka1121/article/details/53395628
我们在面试的时候经常被问到你如何对数据库优化？动不动就分库分表，但是实际上有几个有分库分表的经验呢？下面我们将介绍优化数据库的各个阶段。
explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。
1、参考书籍：MYSQL 5.5从零开始学 Mysql性能优化就算通过合理安排资源，调整系统参数使MYSQL运行更快，更节省资源。MYSQL性能优化包括查询速度优化，更新速度优化，mysql服务器优化等等。此处，介绍以下几个优化。包含，性能优化的介绍，查询优化，数据库结构优化，mysql服务器优化。 Mysql优化，一方面是找出系统的瓶颈，提高mysql数据库整体的性能，另外一个方面需要合理的结构设计和参数调整，以提高用户操作响应的速度。同时还要尽可能节省系统资源，以便系统可以提供更大负荷的服务。mysql数据库优化是多方面的，原则是减少系统的瓶颈，减少资源的占用，增加系统反应的速度。
BTree索引，主流有两种，一种是B树,每一个叶子节点和中间节点中都存在有数据和指针；另一个是B+树，所有的数据都存储在叶子节点，中间节点也是一个索引。
天天听人家说 ”查询优化“，以前用sqlite的时候总是不能理解，优化啥？不就那么些语句嘛。 入门MySQL之初，老师讲过一些，大致有点了解。入门（二）的时候写了索引，又了解了一点。 今天再来了解一下具体该如何个 ”查询优化“法。
在InnoDB中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表（IOT），InnoDB使用B+树索引模型，数据都是存储在B+树中的。
不允许出现相同的值，且不能为NULL值，一个表只能有一个primary_key索引。
针对索引失效的排查，关键步骤包括确定需要分析的SQL语句，并通过EXPLAIN查看其执行计划。主要关注type、key和extra这几个字段。
由此可见，null和''的查询方式不同。而且比较字符 ‘=’’>’ ‘<’ ‘<>’不能用于查询null， 如果需要查询空值（null），需使用is null 和is not null。
如何加快查询，最直接有效的办法就是增加索引，在不使用索引的情况下试图采用其他方式加快查询就是在浪费时间。本文先介绍下MySQL索引的基本数据结构，再对索引的基本规则做下总结。
索引合并是MySQL查询优化器在处理复杂查询条件时使用的一种技术。简单来说，当WHERE子句中有多个条件，并且每个条件都可以利用不同的索引时，优化器会考虑将这些索引的扫描结果合并，从而得到最终的结果集。
MySQL在执行查询语句时使用那个索引是由server层的优化器决定的。优化器的作用是找到一个最优的执行方案，用最小的代价去执行语句。由于MySQL使用预估的方式去选择索引，所以MySQL可能会出现选择索引出错的情况，无法命中最优索引。
[code]– 默认情况下” ; ” 代表sql语句的结束 delimiter 新的界定符 – 修改 // 为界定符 delimiter //
MySQL8.0.18在上个月已经正式发布了，令人兴奋的是带来了Hash Join，今天体验一下Hash Join是否能带来性能上的提升。
今天客户那边遇到一个问题：多选文件进行操作，数据量一大后台处理就特别慢，浏览器显示504超时。为了验证问题是否出在sql语句，所以用以下方法来分析：
刚入职的时候，同事就提醒过我，涉及三四张表的时候，数据量大，尽量不用连表查询，用单表。我最近还真的是遇到了。因为联表查询导致引发的慢sql。
直接遍历这一行行数据，性能就是O(n)，比较慢。为了加速查询，使用了B+树来做索引，将查询性能优化到了O(lg(n))。
我们在开发的过程中使用分页是不可避免的，通常情况下我们的做法是使用limit加偏移量：select * from table where column=xxx order by xxx limit 1,20。当数据量比较小时（100万以内），无论你翻到哪一页，性能都是很快的。如果查询慢，只要在where条件和order by 的列上加上索引就可以解决。但是，当数据量大的时候（小编遇到的情况是500万数据），如果翻到最后几页，即使加了索引，查询也是非常慢的，这是什么原因导致的呢？我们该如何解决呢？
一、背景 我们在开发的过程中使用分页是不可避免的，通常情况下我们的做法是使用limit加偏移量：select * from table where column=xxx order by xxx limit 1,20。当数据量比较小时（100万以内），无论你翻到哪一页，性能都是很快的。如果查询慢，只要在where条件和order by 的列上加上索引就可以解决。但是，当数据量大的时候（小编遇到的情况是500万数据），如果翻到最后几页，即使加了索引，查询也是非常慢的，这是什么原因导致的呢？我们该如何解决呢？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
