数据库里有几千个表，这几千个表的结构都是一样的，想查某一列是否为某个值，怎么写SQL语句？
我已经人傻了，没有任何外键，就硬搜，硬搜的话开多线程也要十多秒，太慢了，而且太吃性能了，有没有什么好办法优化一下？
一个表几万行， 但有几千个，看来是为了【性能】，特意做的分表。（其实分区也一样）
所以，无论怎么做，都不可能变成1个表，所以这几千个表，总是要查询的。
所以，目标是2个
1、提高单表的查询性能，这个索引肯定是要建上的
2、提高资源利用率
看看是CPU,磁盘等哪个是瓶颈，如果有空闲，开多个SQL，分别查询多个表(就是你说的并行查询)
表是根据订单号来创建的，一个订单对应一张设备信息表，然后有一个订单信息表存储所有订单号，创建时间等
设备信息表有七八千张，也就是七八千个订单，设备信息表里面就是一些设备的基本信息，比如编号，录入时间之类的
做一个CDC程序把数据同步至OLAP存储引擎做分析，主要就是把几千张表整到一张表里，一亿不到的话基本都可以毫秒级响应，实在需要关系型存储也可以使用TiDB这种分布式大号MySQL，即使使用PostgreSQL一个亿单表简单查询走索引也不会十多秒
为什么会有几千个表，这些表单表数据没有共同特征么？比如时间？
有的话就能减少工作量了。
没有的话，我有个想法，就是先查一半，再查一半里面的一半，二分法来查
表的结构都是一样的？有几千个表？是否可以考虑再表中加上特殊的字段。
把数据导入到es中查
看样子你这个库只是用于数据采集,并非是针对数据分析建立,因此建议再建个专门用于数据分析的数据仓,把你这些数据都同步进去,多个表的都合到一个表里去。
而且你说的"设备信息表有七八千张，也就是七八千个订单"这个很难理解啊,意思是每新产生一个订单就新建一张设备信息表？一张设备信息表里的数据不会增加？那这个设计是为了干啥啊？为啥不把这些设备信息都放到一个表里去？七八千行也不多呀
看你的情况，只能通过空间换时间的方式了。主要是 这些数据在设计的时候，就没考虑为 末端字段 建立查询机制。
你要查询的 内容，是否是特定设备 的信息？是否是特定类型订单的信息？是否是特定时间的信息？通过数据的相关性，缩小范围。
这个字段，内容是否有规律？或者内容固定的模式？可以通过布隆串，对表字段建立 摘要。
上面都是猜测，没有相关的现场信息和数据可分析。
定时任务后台查出来你要的数据，存在redis，前端请求时先去redis找，找不到再去查。
简单粗暴，写个脚本，for循环，用同步工具列如sqoop把数据同步到hive里面，按天分区，直接使用hive查询，如果硬件资源充足，有现成的引擎例如impala，Doris，也更快了。