回答来自于问答智囊团成员：王文安@DBA 专栏：https://cloud.tencent.com/developer/user/7566357 原因剖析 实际上是MySQL 8.0为了提高information_schema的查询效率，将表和统计信息放入内部的统计信息缓存起来，缓存时间由参数information_schema_stats_expiry决定，至少为86400s；如果想获取最新的统计信息，可以通过如下两种方式： （1）分析表进行表分析 （2）设置information_schema_stats_expiry = 0 继续探索 那么统计信息不准确，会带来哪些影响呢？或者会影响执行计划呢？然后我们再次进行测试 测试1：表test记录数100，表sbtest1记录数100w 执行如下SQL，查看执行计划，走的是NLJ，小表test作为驱动表（全表扫描），大表sbtest1作为被驱动表（主键关联），执行效率很快 mysql >从测试中选择count （* ） ；+ - - - - - + | 数（* ）| + - - - - - + | 100 | + - - - - - + 1行中集合（0.00秒） mysql >从sbtest1选择计数（* ） ; + - - - - - + | 数（* ）| + - - - - - + | 1000000 | + - - - - - + 1行中集合（0.02秒） mysql >从table_name = 'test'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | 测试 | 100 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.00秒） mysql >从table_name = 'sbtest1'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | sbtest1 | 947468 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.01秒） mysql >选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' ; + - - + - - - - + - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | id | k | c | 垫 | + - - + -- - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 1 | 501885 | 08566691963 - 88624912351 - 16662227201 - 46648573979 -64646226163 - 77505759394 - 75470094713 - 41097360717 - 15161106334 - 50535565977 | 63188288836 - 92351140030 - 06390587585 - 66802097351 - 49282961843 | + - - + - - - - + - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - + 1行中 集合 （0.00秒） mysql >说明选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。Ç = ' 08566691963 - 88624912351 - 16662227201 - 4664 + - - + - - - - - - - + - - -- + - - - - - - + - - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - + - - - + - - - - - + - - - - - -- + | id | select_type | 桌子| 隔板| 键入 | 可能的钥匙| 关键 | key_len | 参考 | 行| 过滤| 额外 | + - - + - - - - - - - + - - - - + - - - - - - + -- - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - - + - - - + - - - - - + - - - - - - - + | 1 | SIMPLE | t |NULL | 全部 | 主要 | NULL | NULL | NULL | 100 | 10.00 | 使用Where | | 1 | SIMPLE | t1 | NULL | eq_ref | 主要 | 主要| 4 | 测试。Ť 。id | 1 | 10.00 | 使用Where | + - -+ - - - - - - - + - - - - + - - - - - - + - - - - + - - - - - - - - - + - - - - - + - - - - - + - - - - - - + - - - +- - - - - + - - - - - - - + 2行中 集合， 1个 警告 （0.00秒） 测试2：表test记录数1000w左右，表sbtest1记录数100w 再次执行SQL，查看执行计划，走的也是NLJ，相对小表sbtest1作为驱动表，大表测试作为被驱动表，也是正确的执行计划 mysql >从测试中选择count （* ） ；+ - - - - - + | 数（* ）| + - - - - - + | 10000100 | + - - - - - + 1行中集合（0.33秒） mysql >从sbtest1选择计数（* ） ; + - - - - - + | 数（* ）| + - - - - - + | 1000000 | + - - - - - + 1行中集合（0.02秒） mysql >从table_name = 'test'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | 测试 | 100 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.00秒） mysql >从table_name = 'sbtest1'的表中选择table_schema ， table_name ， table_rows ; + - - - - - - - + - - - - - - + - - - - - - + | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | + - - - - - - - + - - - - - - + - - - - - - + | 测试 | sbtest1 | 947468 | + - - - - - - - + - - - - - - + - - - - - - + 1行中 集合 （0.01秒） mysql >选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' ; + - - + - - - - + - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | id | k | c | 垫 | + - - + -- - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | 1 | 501885 | 08566691963 - 88624912351 - 16662227201 - 46648573979 -64646226163 - 77505759394 - 75470094713 - 41097360717 - 15161106334 - 50535565977 | 63188288836 - 92351140030 - 06390587585 - 66802097351 - 49282961843 | + - - + - - - - + - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - + 1行中 集合 （0.37秒） mysql >说明选择t 。* 来自于t的测试t内部联接sbtest1 t1 。id = t1 。id在哪里t 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'和t1 。c = '08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' ; + - - + - - - - - - - + - - -- + - - - - - - + - - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - + - - - - + - - - - - + - - - - - -- - + | id | select_type | 桌子| 隔板| 键入 | 可能的钥匙| 关键 | key_len | 参考 | 行 | 过滤| 额外 | + - - + - - - - - - - + - - - - + - - - - - - +- - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - - + - - - - + - - - - - + - - - - - - - + | 1 | SIMPLE |t1 | NULL | 全部 | 主要 | NULL | NULL | NULL | 947468 | 10.00 | 使用Where | | 1 | SIMPLE | t | NULL | eq_ref | 主要 | 主要| 4 | 测试。T1 。id | 1 | 10.00 | 使用Where | + - - + - - - - - - - + - - - - + - - - - - - + - - - - + - - - - - - - - + - - - - - + - - - - - + - - - - - - + - --- - - + - - - - - + - - - - - - - + 2行中集合，1个警告（0.01秒） 为什么优化器没有选择错误的执行计划呢？之前文章也提过，MySQL 8.0是将元数据信息存放在MySQL库下的数据字典表里，information_schema库只是提供相对方便的视图供用户查询，所以优化器在选择执行计划时，会从数据字典表中获取统计信息，生成正确的执行计划。 总结 MySQL 8.0为了提高information_schema的查询效率，将视图和表的内部信息统计缓存起来，缓存时间由参数information_schema_stats_expiry决定（建议设置该参数为0）；这可能会导致用户查询上方视图时，无法获取最新，准确的统计信息，但并不会影响执行计划的选择。

对表构造适当的索引，使用Join来替代子查询，然后使用exists语法来简化查询语句，可以适当对空结果集进行判断。

回答来自于问答智囊团成员：王文安@DBA 专栏：https://cloud.tencent.com/developer/user/7566357 怎么看懂 CPU 使用率 以 Linux 的 top 命令为例，效果如下： 📷 Top 命令 在 %CPU 这一列就展示了 CPU 的使用情况，百分比指代的是总体上占用的时间百分比： %us：表示用户进程的 CPU 使用时间（没有通过 nice 调度） %sy：表示系统进程的 CPU 使用时间，主要是内核使用。 %ni：表示用户进程中，通过 CPU 调度（nice）过的使用时间。 %id：空闲的 CPU 时间 %wa：CPU 运行时在等待 IO 的时间 %hi：CPU 处理硬中断花费的时间 %si：CPU 处理软中断花费的时间 %st：被虚拟机偷走的 CPU 时间 通常情况下，我们讨论的 CPU 使用率过高，指的是 %us 这个指标，监控里面的 CPU 使用率通常也是这个值（也有用其他的方法计算出来的，不过简单起见，不考虑其他的情况 ）。其他几个指标过高也代表出 MySQL 的状态异常，简单起见，这里主要还是指 %us 过高的场景。 MySQL 和线程 MySQL 是单进程多线程的结构，意味着独占的 MySQL 服务器里面，只能用 top 命令看到一行数据。 📷 TOP 命令效果 这里能看到的是 MySQL 的进程 ID，如果要看到线程的情况，需要用top -H 📷 TOP 命令效果 在这里能看到的是 MySQL 各个线程的 ID，可以看到 MySQL 在启动之后，会创建非常多的内部线程来工作。 这些内部线程包括 MySQL 自己用来刷脏，读写数据等操作的系统线程，也包括处理用户 SQL 的线程，姑且叫做用户线程吧。用户线程有一个特殊的地方：程序端发送到 MySQL 端的 SQL，只会由一个用户线程来执行（one-thread-per-connection），所以 MySQL 在处理复杂查询的时候，会出现“一核有难，多核围观”的尴尬现象。 参考 %us 的定义，对于 Linux 系统来说，MySQL 进程和它启动的所有线程都不算内核进程，因此 MySQL 的系统线程和用户线程在繁忙的时候，都会体现在 CPU 使用率的 %us 指标上。 MySQL 干什么的时候，CPU 会 100% 从前文的分析来看，MySQL 主要是两类线程占用 CPU：系统线程和用户线程。因此 MySQL 独占的服务器上，只需要留意一下这两类线程的情况，就能 Cover 住绝大部分的问题场景。 系统线程 在实际的环境中，系统线程遇到问题的情况会比较少，一般来说，多个系统线程很少会同时跑满，只要服务器的可用核心数大于等于 4 的话，一般也不会遇到 CPU 100%，当然有一些 bug 可能会有影响，比如这个： 📷 MySQL BUG 虽然情况比较少，但是在面对问题的常规排查过程中，系统线程的问题也是需要关注的。 用户线程 提到用户线程繁忙，很多时候肯定会第一时间凭经验想到慢查询。确实 90% 以上的时候都是“慢查询”引起的，不过作为方法论，还是要根据分析再去得出结论的~ 参考 us% 的定义，是指用户线程占用 CPU 的时间多少，这代表着用户线程占用了大量的时间。 一方面是在进行长时间的计算，例如：order by，group by，临时表，join 等。这一类问题可能是查询效率不高，导致单个 SQL 语句长时间占用 CPU 时间，也有可能是单纯的数据量比较多，导致计算量巨大。另一方面是单纯的 QPS 压力高，所以 CPU 的时间被用满了，比如 4 核的服务器用来支撑 20k 到 30k 的点查询，每个 SQL 占用的 CPU 时间并不多，但是因为整体的 QPS 很高，所以 CPU 的时间被占满了。 怎么定位问题？ 分析完之后，就要开始实战了，这里根据前文的分析给出一些经典的 CPU 100% 场景，并给出简要的定位方法作为参考。 PS：系统线程的 bug 的场景 skip，以后有机会再作为详细的案例来分析。 慢查询 在 CPU 100% 这个问题已经发生之后，真实的慢查询和因为 CPU 100% 导致被影响的普通查询会混在一起，难以直观的看 processlist 或者 slowlog 来发现元凶，这时候就需要一些比较明确的特征来进行甄别。 从前文的简单分析可以看出来，查询效率不高的慢查询通常有以下几种情况： 全表扫描：Handler_read_rnd_next 这个值会大幅度突增，且这一类查询在 slowlog 中 row_examined 的值也会非常高。 索引效率不高，索引选错了：Handler_read_next 这个值会大幅度的突增，不过要注意这种情况也有可能是业务量突增引起的，需要结合 QPS/TPS 一起看。这一类查询在 slowlog 中找起来会比较麻烦，row_examined 的值一般在故障前后会有比较明显的不同，或者是不合理的偏高。 比如数据倾斜的场景，一个小范围的 range 查询在某个特定的范围内 row_examined 非常高，而其他的范围时 row_examined 比较低，那么就可能是这个索引效率不高。 排序比较多：order by，group by 这一类查询通常不太好从 Handler 的指标直接判断，如果没有索引或者索引不好，导致排序操作没有消除的话，那么在 processlist 和 slowlog 通常能看到这一类查询语句出现的比较多。 当然，不想详细的分析 MySQL 指标或者是情况比较紧急的话，可以直接在 slowlog 里面用 rows_sent 和 row_examined 做个简单的除法，比如 row_examined/rows_sent > 1000 的都可以拿出来作为“嫌疑人”处理。这类问题一般在索引方面做好优化就能解决。 PS：1000 只是个经验值，具体要根据实际业务情况来定。 计算量大 这一类问题通常是因为数据量比较大，即使索引没什么问题，执行计划也 OK，也会导致 CPU 100%，而且结合 MySQL one-thread-per-connection 的特性，并不需要太多的并发就能把 CPU 使用率跑满。这一类查询其实是是比较好查的，因为执行时间一般会比较久，在 processlist 里面就会非常显眼，反而是 slowlog 里面可能找不到，因为没有执行完的语句是不会记录的。 这一类问题一般来说有三种比较常规的解决方案： 读写分离，把这一类查询放到平时业务不怎么用的只读从库去。 在程序段拆分 SQL，把单个大查询拆分成多个小查询。 使用 HBASE，Spark 等 OLAP 的方案来支持。 高 QPS 这一类问题单纯的就是硬件资源的瓶颈，不论是 row_examined/rows_sent 的比值，还是 SQL 的索引、执行计划，或者是 SQL 的计算量都不会有什么明显问题，只是 QPS 指标会比较高，而且 processlist 里面可能什么内容都看不到，例如： 📷 processlist 总结一下 实际上 CPU 100% 的问题其实不仅仅是单纯的 %us，还会有 %io，%sys 等，这些会涉及到 MySQL 与 Linux 相关联的一部分内容，展开来就会比较多了。本文仅从 %us 出发尝试梳理一下排查&定位的思路和方法，在分析 %io，%sys 等方面的问题时，也可以用类似的思路，从这些指标的意义开始，结合 MySQL 的一些特性或者特点，逐步理清楚表象背后的原因。

回答来自于问答智囊团成员：vkyzhao 专栏：https://cloud.tencent.com/developer/column/86410 背景 用户反馈实例视图无法访问，与用户沟通后，了解到近期安全变更将部分用户绑定的ip从％转换客户端ip地址，发生故障后，用户紧急进行了回滚，查看访问恢复正常，业务恢复。 分析 首先mysql族的关系数据库，帐户组成由用户@ip共同决定，对其中任意结构的变更都将破坏原来帐户的定义。针对于用户的描述，包括关键行为：1，删除帐户（变更相当于删除之前的帐户）； 2，视图无法使用； 3，修复帐户后又恢复。我们估计是视图的definer被删除导致，查看用户故障视图，果然发现其定义者就是被删除的用户。换一种说话，由于进入definer（由user @ ip组成）在mysql.user表中被删除，导致该视图无法正常提供访问。 ### https ：// // mariadb 。com / kb / zh /创建视图/ 如果指定DEFINER子句，则这些规则将确定合法的DEFINER用户值： 如果你也没有SUPER权限，只有合法用户价值是你自己的帐号，从字面上或使用CURRENT_USER要么指定。您不能将定义器设置为其他帐户。 如果您具有SUPER特权，则可以指定任何语法上合法的帐户名。如果该帐户实际上不存在，则会生成警告。 如果SQL SECURITY值为DEFINER，但是在引用该视图时定义器帐户不存在，则会发生错误。 其流程图可以展示为： 📷 故障流程图 扩展 我们以一个测试的mariadb视图创建语句来做分析 MariaDB的[阿兰] >示出创建视图AAA \ G变 ** ** ** ** ** ** ** ** ** ** ** ** ** * 1 。行** ** ** ** ** ** ** ** ** ** ** ** ** * 视图： aaa 创建视图： CREATE ALGORITHM = UNDEFINED DEFINER = `vky` @ `％` SQL安全性定义视图`aaa`作为select`alan`。哈。`id` AS `id`，`alan`。哈。`name` AS `name` 从 `ha` character_set_client字符： UTF8 collat​​ion_connection是： utf8_general_ci 1行中 集合， 1个 警告 （0.00秒） 其中view列的意义是视图的名称，character_set_client列和collat​​ion_connection列为视图使用到的字符集和排序规则；创建视图其中包含了视图的主体结构，分类如下：1，ALGORITHM =未定义的算法表示实例对视图的处理算法，这个参数有三个值，包括MERGE，TEMPTABLE以及未定义值，其中合并可以简单地理解为将外部的sql语句和视图定义的语句合并起来，到原表进行查询； TEMPTABLE与合并相对应，他将视图中的结果先存储到临时表，外部sql直接调用临时表中的结果；至于未定义，可以理解为实例按照场景自己决定使用哪一个处理算法。2，DEFINER =`vky` @`％ DEFINER表示视图的定义者（包括用户名以及绑定的ip），通常可以显式的指定，转换到当前用户，也就是选择current_user（）;返回的用户。3，SQL SECURE DEFINER SQL SECURITY约束视图的安全性策略，他的值有DEFINER和INVOKER。其中DEFINER的策略为如果引用者存有引用该视图的权限（该视图的选择权限），通常可以成功返回结果；如果为INVOKER，他需要引用视图的账户也需要同时对视图中的原表具有选择的权限，否则也会返回报错。 回到我们故障场景，用户修改了视图定义者的主机之后，导致视图无法访问，这里我们前面也进行了充分的解释，更进一步，既然不能破坏user @ host这个结构，那我们破坏掉这个用户的我们对SQL安全性进行解释，中定义definer策略下，当前帐户只需要有尝试的选择权限即可以正常的引用，其中对原表数据访问实际上使用到了定义者的权限，如果我们对定义者的权限进行完全破坏，实际上也是会失去对视图的使用。以下截屏是我们测试的结果： MariaDB的[阿兰] >示出了补助为vky @ '％' ; + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - + | 赠款用于vky @ ％ | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - + | *允许使用。* TO 'vky' @ '％' IDENTIFIED BY PASSWORD '* 96A12F0614169E80CC46E92BDE3DBF0FD4751D7C' | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - + 1行于 集 （0.00秒） MariaDB [ alan ] >从aaa中选择* ； ERROR 1356 （ HY000 ）：查看“alan.aaa”引用了无效的表（小号）或列（小号）或函数（小号）或定义者/调用者的观点缺乏权限来使用它们 MariaDB的[阿兰] >示出了补助为vky @ '％' \ G变 ** ** ** ** ** ** ** ** ** ** ** ** ** * 1 。排** ** ** ** ** ** ** ** ** ** ** ** ** * 拨款用于vky @ ％： GRANT SELECT ， INSERT ， UPDATE ， DELETE， CREATE ， DROP ，工艺，参考文献，索引， ALTER ， SHOW DATABASES ，创建临时表， LOCK TABLES ， EXECUTE ， REPLICATION SLAVE ， REPLICATION CLIENT ， CREATE VIEW ， SHOW VIEW ， CREATE ROUTINE ， ALTER ROUTINE ，事件，触发* 。* TO 'vky' @ '％' IDENTIFIED BY PASSWORD'* 96A12F0614169E80CC46E92BDE3DBF0FD4751D7C' 1行中 集合 （0.00秒） MariaDB [ alan ] >从aaa中选择* ；+ - - + - - - + | id | 名称| + - - + - - - + | 1 | 艾伦| | 2 | 笑话| | 3 | 汤姆 | + - - + - - - + 3行 在 组 （0.00秒） 同样的逻辑，在invoker策略下，虽然删除定义者不会影响其他拥有权限的用户引用视图，但是这里也跑偏了创建视图的初衷。 那要如何完成变更definer操作呢？ 由于云上实例通常不存在超级权限，因此无法直接使用超级帐户直接将视图从a关联到b名下，但是却可以使用b帐户登录实例，对视图进行definer的变更操作。如截屏： MariaDB的[阿兰] >示出创建表AAA \ G变 ** ** ** ** ** ** ** ** ** ** ** ** ** * 1 。行** ** ** ** ** ** ** ** ** ** ** ** ** * 视图： aaa 创建视图： CREATE ALGORITHM = UNDEFINED DEFINER = `vky` @ `％` SQL安全性定义视图`aaa` AS select`ha`。`id` AS `id`，`ha`。`name` AS `name` 从 `ha` character_set_client字符： UTF8 collat​​ion_connection是： utf8_general_ci 1行中 集合 （0.00秒） MariaDB [ alan ] > alter ALGORITHM =未定义的定义程序= `vky` @ `10.％` SQL安全定义程序视图`aaa` AS选择`ha`。`id` AS `id`，`ha`。`name` AS `name` 从 `ha` ; 查询正确， 受影响0行（0.00秒） MariaDB的[阿兰] >示出创建表AAA \ G变 ** ** ** ** ** ** ** ** ** ** ** ** ** * 1 。行** ** ** ** ** ** ** ** ** ** ** ** ** * 视图： aaa 创建视图： CREATE ALGORITHM = UNDEFINED DEFINER = `vky` @ `10.％` SQL安全性定义视图`aaa` AS select`ha`。`id` AS `id`，`ha`。`name` AS `name` 从 `ha` character_set_client字符： UTF8 collat​​ion_connection是： utf8_general_ci 1行中 集合 （0.00秒） MariaDB [阿兰] >选择current_user （）; + - - - - - - - - + | current_user （） | + - - - - - - - - + | vky @ 10 。％ | + - - - - - - - - + 1行中 集合 （0.00秒） MariaDB [阿兰] > 该操作完成之后，，用户方可进行对高风险用户（绑定％的用户）进行回收操作。

简要分析 MySQL 在创建用户的时候，一般是需要指定用户名和来源 IP 的，比如： mysql> show grants for test@'%'; +----------------------------------+ | Grants for test@% | +----------------------------------+ | GRANT USAGE ON *.* TO 'test'@'%' | +----------------------------------+ 1 row in set (0.00 sec) 由于 Host 这个字段支持正则匹配，因此这个字段设置为 % 的时候，则代表所有的来源 IP 都能匹配到。 因为这个特性，所以有时候创建的账号会有如下的情况出现： +------+---------------+ | user | host | +------+---------------+ | test | % | | test | 10.104.% | | test | 10.104.56.136 | +------+---------------+ 参考官方文档的描述： When multiple matches are possible, the server must determine which of them to use. It resolves this issue as follows: 1.Whenever the server reads the user table into memory, it sorts the rows. 2.When a client attempts to connect, the server looks through the rows in sorted order. 3.The server uses the first row that matches the client host name and user name. The server uses sorting rules that order rows with the most-specific Host values first. 简而言之：MySQL 会按照 Host 的匹配精度，按降序排列同一个 Username 的所有账号，当 Client 端尝试登录 MySQL 的时候，会按照顺序依次这个 Username 下面所有的 Host 规则，直到匹配成功。 Host 这个字段不仅能填 IP，也能写域名，同样也能利用到正则表达式匹配： 📷 匹配示例 由于域名指向的 IP 受 DNS 的影响，因此多数时候会用 IP，一般来说需要 DNS 来屏蔽一些后端细节的时候才会用域名来作为 Host 字段的值。 测试一下 使用如下操作创建三个用户，密码不做区分： mysql> create user test@'%' identified by 'test'; Query OK, 0 rows affected (0.00 sec) mysql> create user test@'10.104.56.136' identified by 'test'; Query OK, 0 rows affected (0.00 sec) mysql> create user test@'10.104.%' identified by 'test'; Query OK, 0 rows affected (0.01 sec) mysql> mysql> mysql> mysql> select user,host from mysql.user where user='test' order by host desc; +------+---------------+ | user | host | +------+---------------+ | test | 10.104.56.136 | | test | 10.104.% | | test | % | +------+---------------+ 3 rows in set (0.00 sec) mysql> PS：order by desc 仅为展示上的考虑。 那么从两个不同的机器上（10.104.56.136 和 10.104.43.107）尝试登录 MySQL，按照文档的描述，匹配的优先级应该是：10.104.56.136->10.104.%->%。那么有一台服务器能完整匹配到 IP，另外一台服务器匹配到的应该是10.104.%。 实际操作一下看看效果： root@debian:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.104.56.136 ......(省略) root@debian:~# mysql -h192.168.1.100 -utest -ptest ......(省略) Server version: 5.7.18-txsql-log 20200331 ......(省略) mysql> show grants; +----------------------------------------------+ | Grants for test@10.104.56.136 | +----------------------------------------------+ | GRANT USAGE ON *.* TO 'test'@'10.104.56.136' | +----------------------------------------------+ 1 row in set (0.00 sec) mysql> 在另外一台机器上： root@VM-43-107-debian:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.104.43.107 ......(省略) root@debian:~# mysql -h192.168.1.100 -utest -ptest ......(省略) Server version: 5.7.18-txsql-log 20200331 ......(省略) mysql> show grants; +-----------------------------------------+ | Grants for test@10.104.% | +-----------------------------------------+ | GRANT USAGE ON *.* TO 'test'@'10.104.%' | +-----------------------------------------+ 1 row in set (0.00 sec) mysql> 换成本地的设备再试一下登录： Tomo@MacBook-Pro ~ % mysql -hgz-cdb.sql.tencentcdb.com -utest -ptest -P59888 ......(省略) Server version: 5.7.18-txsql-log 20200331 ......(省略) mysql> show grants; +----------------------------------+ | Grants for test@% | +----------------------------------+ | GRANT USAGE ON *.* TO 'test'@'%' | +----------------------------------+ 1 row in set (0.02 sec) mysql> 可以看到本地设备的 IP 由于和前两个匹配规则不一致，所以最后匹配到了 % 的这个账号。 总结一下 作为比较保险的办法，尽量少用 Host 来区分不同的账号，直接用不同的 Username 会比较好管理和维护，如果一定需要用 Host 来区分，那么至少也要用不同的密码，防止匹配到了错误的用户，导致权限不足引起业务上的问题。 课外题 localhost 和 127.0.0.1 算是常用的两个 Host，可以作为实践内容动手试一下，体验一下匹配的规律。在 MySQL 看来，精确的域名和精确的 IP 是同等地位的。

TXSQL是腾讯基础架构部数据库团队自研的MySQL分支，对腾讯云以及众多的内部业务提供了强大的数据库内核支撑。相比原生的MySQL，TXSQL在BINLOG复制和InnoDB存储引擎方面做了很多的优化，另外在Server层面也做了大量的工作。因此TXSQL拥有更好的性能，更好的稳定性和可维护性，以及更多的企业级特性。

你在 handleResult 方法中的 list.add 方法调用的前后分别打印一些日志，输出此时 list 中的数据，看看是不是有多次调用和重复数据插入。

创建工单问问客服吧，真的出现这种情况，可就是事故了。 自己还是要做好每天的数据库备份才行。

这个错误表示在添加外键约束时，引用表（employee）中缺少被引用的列（emp_id）。在添加外键约束之前，需要确保引用表中存在被引用的列。您需要检查employee表中是否存在emp_id列，并确保该列的名称和数据类型与约束中指定的一致。

当使用二级索引+回表的方式进行查询时，如果索引列中的重复值过多，就会导致大量的回表操作。 这是因为MySQL的二级索引结构是B+树，B+树的叶子节点存储了数据行的主键值和其它字段的值，而非主键值的索引列只是作为B+树的一部分，用于定位到叶子节点。因此，当查询条件中包含非主键值的索引列时，MySQL需要先通过B+树定位到叶子节点，再根据叶子节点中的主键值回表查询数据行。 如果索引列中重复值过多，那么同一个叶子节点中可能会包含大量的数据行，这就意味着需要进行大量的回表操作才能获取所有符合查询条件的数据行。这将导致查询性能变得非常低下，甚至会出现性能瓶颈。 因此，为了避免这种情况，我们可以在创建索引时尽量避免选择重复值过多的列作为索引列，或者使用联合索引来减少重复值过多的情况。

不建议使用自增列作为shardkey。 建议结合业务与实体关联关系，选择适当的查询关联字段选定shardkey，访问数据尽量都带上 shardkey 字段，若不带 shardkey 的 SQL 会路由到所有节点。 另外需要注意shardkey 字段必须是主键以及所有唯一索引的一部分。

可以通过mysql客户端加上-c选项连接proxy后，执行 /*proxy*/ show help; 查看有没你需要的命令； 例如： /*proxy*/ show config; /*proxy*/ show status; 等命令，查看对应的信息。

确认一下插入数据的表是否有主键或者是唯一索引。 如果没有，会导致数据重复插入。

可以参考：https://cloud.tencent.com/document/product/571/45844

谁能给flyway插件论坛提一下，这个是bug，我换了8.0beta版本的插件就好了，其他的一点也没改，应该是bug了！！！

扫描器扫描的，盲猜扫描

不需要，left join，right join，full join的类型是outer join，单写join的类型是inner join，因此不同join的类型是不言自明，无论是否写出inner或outer，对理解、性能都没有区别。 （来源：灯塔小明的实践经验，不代表腾讯灯塔/智能数据分析的建议或官方推荐。）

用kettle导入到mysql，或者用powerdesigner生成er图都可以

可以的

可以补充一下具体的语句看看