为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【TiDB 版本】v4.0.9
【问题描述】
在dashboard的慢日志中查看到有类似有这样的查询sql；
SELECT
/*!40001 SQL_NO_CACHE */
*
FROM
test;
并且有好几张表，都是不带条件查询的。并且都是用程序账号执行的。感觉有点异常。
1.和开发沟通，他们确定程序没有单独查一个表的，且不带条件查询的。
2.没有使用开发程序账号连接，查询单独表的
3.没有利用开发程序账号导出数据库的
想问问，tidb会出现这样的情况是什么原因啊。有没有数据泄露的可能性。
建议你那边临时开启 tidb_general_log，确认下这个 sql 的来源：
https://docs.pingcap.com/zh/tidb/v4.0/system-variables#tidb_general_log
开启后，建议关注下磁盘空间，如果集群中 sql 量比较大，general log 开启时间越长，写入的数据量越大，占用的磁盘空间相应变大 ~
这个日志开启是不是很影响性能啊。这样的sql不是常有
对性能会有影响，可以在该类 SQL 可能出现的时间段开启 general 来收集，之后再把参数改回来即可。
如果是数据泄露就不知道啥时间段。所以就不好确定这个日志何时开，就怕影响性能。是生产环境的
这个看着怎么那么像连接工具执行的语句？尤其还加了no_cache
慢查询日志里面应该记录了 User@Host 内容，看下用户以及 IP 登陆信息
user 和 host 都是开发的程序账号，IP也是中间件的ip。tidb你们用的没有出现这样的吗。如果用mysqldump导出数据会出现这样的情况，但是我那个时间点，没有导数操作，而且也不会用开发的程序账号。
可以先尝试修改下开发账号的密码，同时设置 max_execution_time 及时 kill 掉这些超时的慢 sql
如果有中间人攻击风险，可以配置启用身份验证 https://docs.pingcap.com/zh/tidb/stable/enable-tls-between-clients-and-servers#配置启用身份验证
好的。
参考下楼上备份的说法，从网上其他说法来看，此种sql基本上都是 MySQL 备份时产生的，查下有没有定时任务之类的，或者有其他备份工具。
对啊，我也是在备份才看到这样的情况，但是我没有这个时间点的备份啊。很奇怪。而且我备份的是用的另一个账号，不会用开发程序用的账号。开发程序账号也不会用来备份的。所以很奇怪。昨天我已经把开发程序账号和密码都换了，今天还是被查了，还查了3次。好几个表。
能否先定位是哪个ip查询的，是否每次都是同一个 ip，如果是，就从这个 ip 开始排查呢
现在已经排查到了，在应用的服务器的其中一台，机器上发现有sql文件。打开SQL文件里面是mysqldump导出的文件开头。
。
发现其中有2张表的数据，但是慢日志里面显示有5个表查询。上午我开了全日志，在全日志里面可以看到这样的一个sql。
[sql="SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE
FILE_TYPE = ‘UNDO LOG’ AND FILE_NAME IS NOT NULL AND LOGFILE_GROUP_NAME IN
(SELECT DISTINCT LOGFILE_GROUP_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = ‘DATAFILE’
AND TABLESPACE_NAME IN (SELECT DISTINCT TABLESPACE_NAME FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_SCHEMA=‘test’ AND TABLE_NAME IN (‘表1’,‘表2’,‘表3’,‘表3’,
‘表4’,‘表5’)))
GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME;】 这个sql里面显示的表，刚好对应我慢日志里面的表。但是我不知道这个是什么原因。是被侵入到服务器了，在服务器上mysqldump了吗？
建议先检查一下定时作业
没有其他的定时任务，定时备份是另一个账号。而且这个不是定时的执行的。
如果上面的备份不是业务需求，你关掉就好了
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。