mysql sql优化面试题？
1.在表中建立索引，优先考虑 where group by 使用到的字段
2.查询时尽量避免使用select * ，只查询需要用到的字段
3.避免在where子句中使用关键字两边都是%的模糊查询，尽量在关键字后使用模糊查询
4.尽量避免在where子句中使用IN 和NOT IN
优化：能使用between就不用in
在子查询中使用exists 子句
mysql analyze对业务表的影响？
MySQL的ANALYZE命令用于收集表的统计信息，以帮助优化查询性能。它会分析表的索引和数据分布，并更新优化器的统计信息。
这可以提高查询的执行计划选择，减少查询的执行时间。
ANALYZE命令对业务表的影响是通过提供更准确的统计信息来改善查询性能，从而提高系统的响应速度和吞吐量。
然而，ANALYZE命令本身可能会占用一定的系统资源和时间，因此在高负载环境中需要谨慎使用，以避免对业务操作产生不必要的影响。
mysql两表关系查询？
我来讲一下这个问题吧：
对于这条sql语句它的执行计划其实并不是先查询出b表的所有id,然后再与a表的id进行比较。
mysql会把in子查询转换成exists相关子查询，所以它实际等同于这条sql语句：select * from a where exists(select * from b where b.id=a.id );
而exists相关子查询的执行原理是: 循环取出a表的每一条记录与b表进行比较，比较的条件是a.id=b.id . 看a表的每条记录的id是否在b表存在，如果存在就行返回a表的这条记录。
exists查询有什么弊端？
由exists执行原理可知，a表(外表)使用不了索引，必须全表扫描，因为是拿a表的数据到b表查。而且必须得使用a表的数据到b表中查（外表到里表中），顺序是固定死的。
如何优化？
建索引。但是由上面分析可知，要建索引只能在b表的id字段建，不能在a表的id上，mysql利用不上。
这样优化够了吗？还差一些。
由于exists查询它的执行计划只能拿着a表的数据到b表查（外表到里表中），虽然可以在b表的id字段建索引来提高查询效率。
但是并不能反过来拿着b表的数据到a表查，exists子查询的查询顺序是固定死的。
为什么要反过来？
因为首先可以肯定的是反过来的结果也是一样的。这样就又引出了一个更细致的疑问：在双方两个表的id字段上都建有索引时，到底是a表查b表的效率高，还是b表查a表的效率高？
mysql可以同时查询多张表吗？
刚超过百万的表真不大，我做过的公司很多表都是几百万，个别的到了千万，对于一般的查询来说可以不用刻意考虑怎么存储的问题，mysql够扛的。而对于复杂的多连表查询，尤其是在做数据统计业务时，sql操作会很复杂，会很慢，但是因为这个业务是对数据的实时性要求不高，我们会采用写定时任务的方式，提前把多张表查询跑成一张最终的结果存储起来，我们业务上的sql直接去查这个最终表就行了。
有人说分表，横着切分。但是我见过的公司通常不会完全这样做，因为分表之后的弊端也很大，会导致有些业务对该数据的操作需求实现不了或者很麻烦。实际的做法是，分表的同时，仍然保留整体的原表，两份数据，一份是原表，另一份是对原表进行切分的副本，用这个分开的表来满足某部分业务的查询需求即可。至于怎么分，看业务，比如说我做过一款手机游戏的app，在统计用户的月活跃情况时，我会按月份分。
抛开具体的业务不谈，在其他方面通常的解决方案还有：
第一：成本最低也是最实用的方式：索引优化、sql优化。
第二：上缓存，查询也不一定完全就是数据量大影响的，高访问量请求数据库密集时，也会影响，用缓存挡在mysql前面，进行流量削锋。
第三：mysql读写分离，其实本质也是一种负载均衡的实现方式。
第四：分布式，把同一份数据分到不同服务器上，这个成本就大了，一般的公司用不到，想满足不同业务的需求对技术要求很高，较难解决的问题是在数据的一致性上。
等等，不管使用什么技术，一定要考虑好这个技术可能带来的后果尤其弊端是什么。