We have two MySQL servers in master master replication. We can see many KILL QUERY statements in MySQL general log specific to stored procedures as below :
2024-03-20T21:54:45.056981+05:30 12996 Query CALL tc_updatemostinterestedinquiry(9546, 1446507, 3)
2024-03-20T21:54:45.068626+05:30 14167 Connect [email protected] on autobiz using TCP/IP
2024-03-20T21:54:45.068978+05:30 14167 Query SET NAMES utf8mb4
2024-03-20T21:54:45.069238+05:30 14167 Query KILL QUERY 12996
2024-03-20T21:54:45.069497+05:30 14167 Quit
2024-03-20T21:54:45.069586+05:30 12996 Query DO SLEEP(0)
2024-03-20T21:54:45.070287+05:30 12996 Query SET NAMES utf8mb4
These stored procedures are called from a .NET application where we use dapper library version 1.60.6
<PackageReference Include="Dapper" Version="1.60.6" />
Stored procedure call syntax in the application is
con.Connection.Query<dynamic>("stored_procedure_name", param, commandType: CommandType.StoredProcedure);
We use MysqlConnector version 1.3.8.
After removing Connection Admin and Super privilege which is required to run the
KILL QUERYstatement from the MySQL user we observeKILL QUERYstatements still exists in the general log. You can check about the privileges requirement here.This
KILL QUERYstatement creates a new connection every time to the MySQL server for execution.We have read about MysqlConnector Command Cancellation which tells there is a possibility of command timeout. But when we call these stored procedures without any commands in it from the application they still give out
KILL QUERYin general log. There are no such long running queries in stored procedures.When connecting to MySQL server via workbench and calling same stored procedures we don't face any
KILL QUERYstatements.
We have been facing this problem since quite long, please help. We dont wish to have these statements in our general log as it bombards the server with new connections.