在特定的 MySQL 线程上执行查询 - IDEA
Execute a query on a particular MySQL thread - IDEA
我有一个想法，但我不确定是否可行。 / 是否已经可用。只是在这里分享我的观点，以获得是否可能的建议 MySQL
问题：
假设在产品功能的查询中做了一个小的更改并在生产中发布，由于此更改需要更多时间才能完成查询的执行。
突然间，此功能的客户激增。然后，由于多次查询此功能，数据库负载很重，由于此功能查询，产品中的其他功能也会在加载数据库时受到影响（其他简单查询）。
为什么会这样：
假设我的 innodb_thread_concurrency 是 20。例如：如果有 100 个这样昂贵的查询进来，MySQL 将使用所有可用的线程并处理查询通过上下文切换。由于这个原因，其他简单的查询也会受到影响。
可能的解决方案之一：
可能会将昂贵的查询移至从属，但在从属和从属加载时仍然会发生相同的情况。
我认为更好的解决方案：
说我的
innodb_thread_concurrency = 20。
CPU核心=36
这里我分配了从CPU到MYSQL的20个线程。在这20个Thread中，我会在Application level做一个拆分，哪个query在哪个thread执行。
根据优先级将20个线程分成3个集合：
线程优先级与线程计数 - 应该是可配置的。
前任：
低优先级：4
中等优先级：6
高优先级：10
高优先级：
- 说很简单的查询。就像查询配置表
- 插入、更新、删除查询
- 基本上这些查询是产品的基本查询 运行
- 大部分在 100 毫秒到 1 秒内执行
中等优先级：
- 不如核心查询重要的查询，可能需要很少的额外时间，主要是 1 - 5 秒
低优先级：
- 记录 Table 查询，分析查询
- 查询时间超过 5 秒
这里的规则是：
-> 配置的查询应该只在特定的 Priority_Threads 中执行，并且上下文切换也应该只在 [=123 中执行=].
-> 所有查询都应该在产品级别配置，查询在哪个 THREAD 中执行，如果此查询简单且重要，将使用 [=53= 执行]High_Priority_Thread，因为我们假设这个查询将在 100 毫秒内执行。
让我们来看看加载数据库并影响所有查询的案例，有了这种支持，我们将在 Low_Priority_Thread 中执行查询。如上所述，如果 100 个此类查询到达 Low_Priority_Thread，只有优先级线程受到影响，因为上下文切换只会发生在 [=126= 之间]。所以其他 Priority_Threads 将是免费的，它们将服务于他们自己分配的查询。
这可以用于不同的用例：
- 如果 Beta 版本中有新功能，我们可以在 Low_Priority_Thread 中执行此查询。如果此功能查询有任何问题，不会影响其他线程中的核心查询。
- 在High_Priority查询中对现有查询所做的任何更改，我们可以更改其Priority_Thread类型暂时降低，直到稳定。
请分享您对此的看法。在 MYSQL 或任何其他数据库中可能有这样的事情吗？
反对线程优先级的案例
我怀疑如果“线程优先级”有用，它们早就被实现了。
这里有一个反对这样的问题：
- 低优先级线程获得一些时间。
- 那个低线程已经锁定了一行，因为他将要更新它。 （比如说，一个“喜欢”计数器。）
- 出现一个高优先级线程并需要该行，但现在已被阻止。 （哎呀，他现在跟低线程一样慢了。）
- 又一个高优先级的线程出现了...好吧，我会让你完成谋杀悬疑故事。
最好的做法（在大多数情况下）是努力加快最慢的查询。优先级不如它能以多快的速度让开更重要。
请记住，“上下文切换”是处理线程间协调所必需的。并且可能开关的数量是相同的，有或没有优先级。
“100 毫秒到 1 秒”——即使是这些也值得优化。
我有时看到的一个问题源于允许太多并发进程。我喜欢杂货店的类比...
拥挤的杂货店类比
简单地说，如果“太多”的人同时在店里，那么很快就没有人会出来；每个人都慢下来了。
现在假设有些人更有特权，而其他人必须靠边站才能让他们走得更快。好吧，假设我（低优先级）可能站在熟食柜台前，单身店员正在为我切肉。您（高优先级）过来要求店员停止处理我的订单以处理您的请求。这会导致店员效率低下（因为半成品的订单坐在切肉机里）。还有更多的顾客会站在你的身后。
高速公路交通
研究表明，高速公路匝道上的计量灯使高速公路 更高效 。是的，这是违反直觉的。另外，高速公路上频繁的变道实际上需要更多space。等等
备选方案
因此，使用慢日志来确定哪些查询类型对系统造成的负担最大，然后提供示例，以及SHOW CREATE TABLE 和EXPLAIN SELECT。我们或许可以加快速度。
MySQL 资源组
MySQL supports creation and management of resource groups, and permits
assigning threads running within the server to particular groups so
that threads execute according to the resources available to the
group. Group attributes enable control over its resources, to enable
or restrict resource consumption by threads in the group. DBAs can
modify these attributes as appropriate for different workloads.
MySQL :: MySQL 8.0 Reference Manual :: 5.1.16 Resource Groups
其他几个参考链接：
https://medium.com/synaptic-tech/scaling-our-platform-using-mysql-8-resource-groups-e7c09d2cedd7
https://dzone.com/articles/mysql-8-load-fine-tuning-with-resource-groups
我有一个想法，但我不确定是否可行。 / 是否已经可用。只是在这里分享我的观点，以获得是否可能的建议 MySQL
问题：
假设在产品功能的查询中做了一个小的更改并在生产中发布，由于此更改需要更多时间才能完成查询的执行。 突然间，此功能的客户激增。然后，由于多次查询此功能，数据库负载很重，由于此功能查询，产品中的其他功能也会在加载数据库时受到影响（其他简单查询）。
为什么会这样：
假设我的 innodb_thread_concurrency 是 20。例如：如果有 100 个这样昂贵的查询进来，MySQL 将使用所有可用的线程并处理查询通过上下文切换。由于这个原因，其他简单的查询也会受到影响。
可能的解决方案之一：
可能会将昂贵的查询移至从属，但在从属和从属加载时仍然会发生相同的情况。
我认为更好的解决方案：
说我的 innodb_thread_concurrency = 20。 CPU核心=36
这里我分配了从CPU到MYSQL的20个线程。在这20个Thread中，我会在Application level做一个拆分，哪个query在哪个thread执行。
根据优先级将20个线程分成3个集合：
线程优先级与线程计数 - 应该是可配置的。 前任： 低优先级：4 中等优先级：6 高优先级：10
高优先级：
- 说很简单的查询。就像查询配置表
- 插入、更新、删除查询
- 基本上这些查询是产品的基本查询 运行
- 大部分在 100 毫秒到 1 秒内执行
中等优先级：
- 不如核心查询重要的查询，可能需要很少的额外时间，主要是 1 - 5 秒
低优先级：
- 记录 Table 查询，分析查询
- 查询时间超过 5 秒
这里的规则是：
-> 配置的查询应该只在特定的 Priority_Threads 中执行，并且上下文切换也应该只在 [=123 中执行=].
-> 所有查询都应该在产品级别配置，查询在哪个 THREAD 中执行，如果此查询简单且重要，将使用 [=53= 执行]High_Priority_Thread，因为我们假设这个查询将在 100 毫秒内执行。
让我们来看看加载数据库并影响所有查询的案例，有了这种支持，我们将在 Low_Priority_Thread 中执行查询。如上所述，如果 100 个此类查询到达 Low_Priority_Thread，只有优先级线程受到影响，因为上下文切换只会发生在 [=126= 之间]。所以其他 Priority_Threads 将是免费的，它们将服务于他们自己分配的查询。
这可以用于不同的用例：
- 如果 Beta 版本中有新功能，我们可以在 Low_Priority_Thread 中执行此查询。如果此功能查询有任何问题，不会影响其他线程中的核心查询。
- 在High_Priority查询中对现有查询所做的任何更改，我们可以更改其Priority_Thread类型暂时降低，直到稳定。
请分享您对此的看法。在 MYSQL 或任何其他数据库中可能有这样的事情吗？
反对线程优先级的案例
我怀疑如果“线程优先级”有用，它们早就被实现了。
这里有一个反对这样的问题：
- 低优先级线程获得一些时间。
- 那个低线程已经锁定了一行，因为他将要更新它。 （比如说，一个“喜欢”计数器。）
- 出现一个高优先级线程并需要该行，但现在已被阻止。 （哎呀，他现在跟低线程一样慢了。）
- 又一个高优先级的线程出现了...好吧，我会让你完成谋杀悬疑故事。
最好的做法（在大多数情况下）是努力加快最慢的查询。优先级不如它能以多快的速度让开更重要。
请记住，“上下文切换”是处理线程间协调所必需的。并且可能开关的数量是相同的，有或没有优先级。
“100 毫秒到 1 秒”——即使是这些也值得优化。
我有时看到的一个问题源于允许太多并发进程。我喜欢杂货店的类比...
拥挤的杂货店类比
简单地说，如果“太多”的人同时在店里，那么很快就没有人会出来；每个人都慢下来了。
现在假设有些人更有特权，而其他人必须靠边站才能让他们走得更快。好吧，假设我（低优先级）可能站在熟食柜台前，单身店员正在为我切肉。您（高优先级）过来要求店员停止处理我的订单以处理您的请求。这会导致店员效率低下（因为半成品的订单坐在切肉机里）。还有更多的顾客会站在你的身后。
高速公路交通
研究表明，高速公路匝道上的计量灯使高速公路 更高效 。是的，这是违反直觉的。另外，高速公路上频繁的变道实际上需要更多space。等等
备选方案
因此，使用慢日志来确定哪些查询类型对系统造成的负担最大，然后提供示例，以及SHOW CREATE TABLE 和EXPLAIN SELECT。我们或许可以加快速度。
MySQL 资源组
MySQL supports creation and management of resource groups, and permits assigning threads running within the server to particular groups so that threads execute according to the resources available to the group. Group attributes enable control over its resources, to enable or restrict resource consumption by threads in the group. DBAs can modify these attributes as appropriate for different workloads.
MySQL :: MySQL 8.0 Reference Manual :: 5.1.16 Resource Groups
其他几个参考链接：
https://medium.com/synaptic-tech/scaling-our-platform-using-mysql-8-resource-groups-e7c09d2cedd7
https://dzone.com/articles/mysql-8-load-fine-tuning-with-resource-groups