下午，我正爽歪歪地喝着咖啡，看着Power BI每秒钟刷新一次，静静等待某个分公司完成本月绩效任务，自动调用Python在钉钉群中发送喜报：
这两天工作和生活上的事情都比较多，工作上要赶好几个OKR任务，搞得节奏有点乱，生活上这几天搬了新家，每天回家都自己做饭吃，再加上打扫房间的卫生，稍微搞一搞就九点十点了，时间变的很紧。今天写文章的时间又比较晚了，就写点简单的内容吧。
然而我们在使用mysql数据库的时候也像字典一样有索引的情况下去查询，肯定速度要快很多
在上文我们曾小小的提到过，在索引失效的情况下，MySQL会把所有聚集索引记录和间隙都锁上，我们称之为锁表，或叫行锁升表锁.
MySQL 的慢查询日志是 MySQL 提供的一种日志记录，它用来记录在 MySQL 中响应时间超过阀值的语句，阈值指的是运行时间超过 long_query_time 值的 SQL，则会被记录到慢查询日志中。long_query_time 的默认值为 10，意思是运行 10秒 以上的语句。默认情况下，MySQL 数据库并不启动慢查询日志，需要我们手动来设置这个参数。 慢查询需要知道的 “点” 企业级开发中，慢查询日志是会打开的。但是这同样会带来一定的性能影响。 慢查询日志支持将日志记录写入文件，也支持将日志记录写入数据库表 默认的阈值（long_query_time）是 10，这个显然不可用，通常，对于用户级应用而言，我们将它设置为 0.2 慢查询相关的变量 查看变量的 SQL 语句
分区是将一个表的数据按照某种方式，比如按照时间上的月份，分成多个较小的，更容易管理的部分，但是逻辑上仍是一个表。我们在此之前已经讲过MySQL分区表的原理，分区有利于管理非常大的表，它采用分而治之的逻辑，便于对数据的管理。本期我们就来进一步了解MySQL分区表，详细看一下MySQL分区表类型究竟有几个？
对于没有索引的表，单表查询可能几十万数据就是瓶颈，而通常大型网站单日就可能会产生几十万甚至几百万的数据，没有索引查询会变的非常缓慢。
大部分的游戏数据库都是使用mysql ,开源，免费是他的法宝，虽然没有oracle 牛逼，但是对于日常的使用，完全够用，所以大多的公司都是使用mysql 作为数据的落地选择，因为之前一直使用的InnoDB 引擎，所以今天今天大概聊一下对数据库的优化原则问题，都是基于InnoDB 引擎，希望你能在遇到同样的问题时能解决问题。OK，我们开始吧。
版权声明：本文为博主原创文章，欢迎扩散，扩散请务必注明出处。 https://blog.csdn.net/robinson_0612/article/details/82824320
本文是在假定读者了解了直方图是什么，直方图如何进行添加维护的前提下，围绕直方图与索引的对比、何时应该添加直方图，及直方图如何帮助优化器选择更优的执行计划这几个方面来介绍直方图。 对直方图不太了解的小伙伴可参考GreatSQL社区的另一篇文章 4.直方图介绍和使用|MySQL索引学习
其实对于上面的观点一定程度上是正确的，但不是完全正确。但之所以流传这么广，主要还是没有搞清楚实际状态，而根据实际使用中总结出来的一些模糊规律。只有了解的MySQL的Join实际执行方式，就会知道上面2种观点是一种模糊的规律，这种规律并不能指导我们实际开发。下面就说说MySQL的实际join执行方式。
http://www.searchdoc.cn/rdbms/mysql/dev.mysql.com/doc/refman/5.7/en/index.com.coder114.cn.html
完全的范式和反范式是不存在的，在实际操作中建议混用这两种策略，可能使用部分范式化的schema、缓存表、以及其他技巧。
大家好，又见面了，我是你们的朋友全栈君。 关于MySQL索引的好处，如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话，那么没有设计和使用索引的MySQL就是一个人力三轮车。对于没有索引的表，单表查询可能几十万数据就是瓶颈，而通常大型网站单日就可能会产生几十万甚至几百万的数据，没有索引查询会变的非常缓慢。还是以WordPress来说，其多个数据表都会对经常被查询的字段添加索引，比如wp_comments表中针对5个字段设计了BTREE（二叉树）索引。
我只知道 innodb 存储引擎 是支持行锁和表锁的，myIsam中 只支持表锁，（表锁的 排他锁好像也就是直接变成串行化的隔离级别了）。不知道什么情况下 行锁会升级为表锁。查看资料后，根据前人做过的经验 来测试一下锁升级的实验。
大家如果看过我之前发过的文章就知道，我写过很多篇关于 MySQL 的文章，从我的 Github 汇总仓库 中可以看出来：
嵌套查询（子查询）可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。嵌套查询写起来简单，也容易理解。但是，有时候可以被更有效率的连接（JOIN)替代。
使表占用尽量少的磁盘空间。减少磁盘I/O次数及读取数据量是提升性能的基础原则。表越小，数据读写处理时则需要更少的内存，同时，小表的索引占用也相对小，索引处理也更加快速。
select查询的序列号，包含一组数字，表示查询中执行select子句或者操作表的顺序 id号分为三种情况： 1、如果id相同，那么执行顺序从上到下 2、如果id不同，如果是子查询，id的序号会递增，id值越大优先级越高，越先被执行 3、id相同和不同的，同时存在：相同的可以认为是一组，从上往下顺序执行，在所有组中，id值越大，优先级越高，越先执行
索引管理 索引是什么？ 索引就好比一本书的目录，它会让你更快的找到内容； 让获取的数据更有目的性，从而提高数据库检索数据的性能； 索引建立在表的列上(字段)。 索引的设计理念 数据库索引的设计原则：
MySQL的基本存储结构是页，记录都存在页里面，下图以聚簇索引为例，页与页之间构成一个双向链表，每个页中的记录又组成一个单向链表，页里边将记录分组，将每组第一个记录的主键提取出来构成一个目录项，目录项是一个数组，叶子结点记录了实际的记录，而非叶子结点并不记录实际记录，只是记录了其孩子结点第一个记录的主键以及所在页号。
索引是一种特殊的文件，包含着对数据表里所有记录的引用指针。可以对表中的一列或多列创建索引并指定索引的类型，各类索引有各自的数据结构实现。 通过目录，就可以快速的找到某个章节对应的位置。=》索引的效果，就是为了加快查找的速度。
视频地址: https://www.bilibili.com/video/BV1zy4y1m7ZS/
今天遇见了一个线上的MySQL问题，问题的内容是某个阿里云ECS频繁报警，报警的内容是：CPU使用率超过阈值。下面是具体的Grafana报警中负载、CPU和磁盘使用率的图像：
mysql 是我们最常用的数据存储的的程序，它是关系数据库的代表，可以直接服务于我们的常规业务，是我们不能离开的数据存储器，对于关系操作复杂的业务，具有很强的优势。
问题1：char、varchar的区别是什么？ varchar是变长而char的长度是固定的。如果你的内容是固定大小的，你会得到更好的性能。
mysql 作为一个关系型数据库，在国内使用应该是最广泛的。也许你司使用 Oracle、Pg 等等，但是大多数互联网公司，比如我司使用得最多的还是 Mysql，重要性不言而喻。
在关系型数据库中设计索引其实并不是复杂的事情，很多开发者都觉得设计索引能够提升数据库的性能，相关的知识一定非常复杂。 然而这种想法是不正确的，索引其实并不是一个多么高深莫测的东西，只要我们掌握一定的方
数据库（Database）是存储与管理数据的软件系统，就像一个存入数据的物流仓库。每个数据库都有一个或多个不同的API接口用于创建，访问，管理，搜索和复制所保存的数据。我们也可以将数据存储在文件中，但是在文件中读写数据速度相对较慢，所以我们使用关系型数据库管理系统（RDBMS）来存储和管理的大数据量。
分库分区分表概念 分区 就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的 。 分表 就是把一张数据量很大的表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。表名可以按照某种业务hash进行映射。 分库 一旦分表，一个库中的表会越来越多。 下面来具体看看 分区 mysql数据库中的数据是以文件的形势存在磁盘上的，默认放在/mysql/data下面（可以通过my.cnf中的datadir来查看），一张表主要对应着三
问题：在矩阵中，随机找到每一行的任意位置作为变点位置，然后把每一行变点位置及其后面的数都赋值为NA
上一篇关于Python和MySQL的简单联调做了学习。 这次主要是将这个过程再优化扩大点。 对教务处需要的数据都进行了处理存进数据库了。 也是对bug问题的总结。
写SQL语句不难，稍微系统学习过数据库相关技术的人都能做到，但想要写好SQL却也不是一件易事，在大多数编写SQL的时候，很多人都是以实现需求为原则去撰写的，当一条SQL写出来之后，只要能满足业务需求就行，不会考虑它有没有优化点，能不能让它跑的更快。
我在 MySQL优化必备之执行计划explain，索引基本知识，索引数据结构推演 里，提到了索引的一些基本概念，提到MySQL优化，很多人第一时间会想到建索引。
本篇介绍 MySQL 表如何计算统计信息。表统计信息是数据库基于成本的优化器最重要的参考信息；统计信息不准确，优化器可能给出不够优化的执行计划或者是错误的执行计划。
在 SQL 进阶技巧 我们简述了 SQL 的一些进阶技巧，一些朋友觉得不过瘾，我们继续来下篇，再送你 10 个技巧
1.查版本号无论做什么都要确认版本号，不同的版本号下会有各种差异。>Select version(数据库
ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。
但是小姐姐解释说，查询结果确实“诡异”的多出了184行，问题变的 interesting
数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。
MySQL的査询优化器会通过两个API来了解存储引擎的索引值的分布信息,以决定如何使用索引。第一个API是 records_in_range()，通过向存储引擎传入两个边界值获取在这个范围大概有多少条记录。对于某些存储引擎，该接口返回精确值，例如MyISAM；但对于另一些存储引擎则是一个估算值，例如 InnoDB。 第二个API是info()，该接口返回各种类型的数据，包括索引的基数(每个键值有多少条记录)。 如果存储引擎向优化器提供的扫描行数信息是不准确的数据，或者执行计划本身太复杂以致无法准确地获取各个阶段匹配的行数，那么优化器会使用索引统计信息来估算扫描行数。 MySQL优化器使用的是基于成本的模型，而衡量成本的主要指标就是一个查询需要扫描多少行。如果表没有统计信息，或者统计信息不准确，优化器就很有可能做出错误的决定。可以通过运行ANALYZE TABLE来重新生成统计信息解决这个问题。 每种存储引擎实现索引统计信息的方式不同，所以需要进行ANALYZE TABLE的频率也因不同的引擎而不同，每次运行的成本也不同：
最近，在 mysql 测试最左前缀原则，发现了匪夷所思的事情。根据最左前缀原则，本来应该索引失效，走全表扫描的，但是，却发现可以正常走索引。
-- select * from information_schema.PROCESSLIST where info is not null;
方法区：主要是存储类信息，常量池（static 常量和 static 变量），编译后的代码（字
我们遇到的最容易引起困惑的问题就是索引列的顺序。正确的顺序依赖于使用该索引的查询，并且同时需要考虑如何更好地满足排序和分组的需要（顺便说明，本节内容适用于B-Tree索引；哈希或者其他类型的索引并不会像B-Tree索引一样按顺序存储数据）。 在一个多列B-Tree索引中，索引列的顺序意味着索引首先按照最左列进行排序，其次是第二列，等等。所以，索引可以按照升序或者降序进行扫描，以满足精确符合列顺序的ORDER BY、GROUP BY和DISTINCT等子句的查询需求。 所以多列索引的顺序至关重要。在“三星索引”系统中，列顺序也决定了一个索引是否能够成为一个真正的“三星索引”。 对于如何选择索引的列顺序有一个经验法则：将选择性最高的列放到索引最前列。这个建议有用吗？在某些场景可能有帮助，但通常不如避免随机IO和排序那么重要，考虑问题需要更全面（场景不同则选择不同，没有一个放之四海皆准的法则。这里只是说明，这个经验法则可能没有你想象的重要）。 当不需要考虑排序和分组时，将选择性最高的列放在前面通常是很好的。这时候索引的作用只是用于优化WHERE条件的查找。在这种情况下，这样设计的索引确实能够最快地过滤出需要的行，对于WHERE子句中只使用了索引部分前缀列的查询来说选择性也更高。然而，性能不只是依赖于所有索引列的选择性(整体基数)，也和查询条件的具体值有关，也就是和值的分布有关。这和选择前缀的长度需要考虑的地方一样。可能需要根据那些运行频率最高的查询来调整索引列的顺序，让这种情况下索引的选择性最高。
如果这条sql是写操作(insert、update、delete)，那么大致的过程如下，其中引擎层是属于 InnoDB 存储引擎的，因为InnoDB 是默认的存储引擎，也是主流的，所以这里只说明 InnoDB 的引擎层过程。由于写操作较查询操作更为复杂，所以先看一下写操作的执行图。方便后面解析。
领取专属 10元无门槛券
手把手带您无忧上云
