Is there middleware for real-time protection? For example, if there is a slow SQL in the program that slows down the database, the database will automatically circuit-break this SQL

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 有事中防护的中间件吗？如程序中有个慢SQL,拖慢数据库，数据库自动对这句SQL熔断

| username: tidb狂热爱好者

Is there any middleware for in-process protection? For example, if there is a slow SQL query in the program that drags down the database, can the database automatically fuse this SQL query?

2
| username: ShawnYan | Original post link

Monitor long-running SQL and then kill it?

3
| username: wzf0072 | Original post link

I’ve long wanted to create a stored procedure and execute it periodically, but I’m worried about unintended consequences.

4
| username: tony5413 | Original post link

You’re talking about the automatic SQL throttling feature, right?
Automatic throttling is mainly applied in the following three scenarios:

  • Traffic issues: Cache penetration or abnormal calls occur, leading to a sharp increase in the concurrency of certain types of SQL.
  • Data issues: An account with large order data, where the related SQL of this account occupies a large amount of database resources.
  • SQL issues: SQL without indexes is called frequently, affecting normal business operations.
5
| username: liuis | Original post link

We have similar issues in our business. When processing data for major clients, it slows down the entire service. Currently, we are just afraid of collateral damage.

6
| username: 啦啦啦啦啦 | Original post link

It might not be appropriate to leave this to middleware or the database. Some business processes are inherently slow, so it is more reasonable to control it at the business level.

7
| username: WalterWj | Original post link

Unverified internal information: There is this idea, and there might be a similar feature in the future.

8
| username: forever | Original post link

Isn’t the MAX_EXECUTION_TIME parameter used for this purpose?

9
| username: liuis | Original post link

As long as the boundaries are defined, it’s like circuit breaking at the service level. Establish a circuit breaking strategy, and let the users control it themselves.

10
| username: wzf0072 | Original post link

TiDB can fuse SQL with excessive memory usage when an OOM (Out of Memory) occurs.

11
| username: WalterWj | Original post link

My idea is to throttle a certain type of SQL.

12
| username: 啦啦啦啦啦 | Original post link

This parameter can easily cause collateral damage if applied uniformly. I think we can use hints or set session-level parameters to allow developers to impose restrictions in the code.

13
| username: forever | Original post link

MySQL can also be set at the SQL level, but it is a bit troublesome to use.

14
| username: Running | Original post link

TiDB does not support stored procedures!

15
| username: Running | Original post link

Add TiDB server nodes specifically to handle these slow SQL queries.

16
| username: wzf0072 | Original post link

Yes, our business is currently running on MySQL, and we are planning to run the reporting and dashboard requirements on TiDB.