数据库运维面试题？
1．事务四大特性（ ACID ）原子性、一致性、隔离性、持久性？
2.事务的并发？事务隔离级别，每个级别会引发什么问题， mysql 默认是哪个级别？
3.MySQL常见的三种存储引擎
( InnoDB 、 MyISAM 、 MEMORY )的区别？
4.MySQL的 MyISAM 与 InnoDB 两种存储引擎在，事务、锁级别，各自的适用场景？
5．查询语句不同元素（ where 、 jion 、 limit 、 group by 、 having 等等）执行先后顺序？
6．什么是临时表，临时表什么时候删除？7. MySQL B + Tree 索引和 Hash 索引的区别？
8.聚集索引和非聚集索引区别？
9．有哪些锁（乐观锁悲观锁）, select 时怎么加排它锁？
10.非关系型数据库和关系型数据库区
数据库面试常问的几个问题？
1．事务四大特性（ ACID ）原子性、一致性、隔离性、持久性？
2.事务的并发？事务隔离级别，每个级别会引发什么问题， mysql 默认是哪个级别？
3.MySQL常见的三种存储引擎
( InnoDB 、 MyISAM 、 MEMORY )的区别？
4.MySQL的 MyISAM 与 InnoDB 两种存储引擎在，事务、锁级别，各自的适用场景？
5．查询语句不同元素（ where 、 jion 、 limit 、 group by 、 having 等等）执行先后顺序？
6．什么是临时表，临时表什么时候删除？7. MySQL B + Tree 索引和 Hash 索引的区别？
8.聚集索引和非聚集索引区别？
9．有哪些锁（乐观锁悲观锁）, select 时怎么加排它锁？
10.非关系型数据库和关系型数据库区
mysql的groupby怎么优化？
在某些情况中，MySQL能够做得更好，通过索引访问而不用创建临时表。GROUPBY使用索引的最重要的前提条件是所有GROUPBY列引用同一索引的属性，并且索引按顺序保存(例如，这是B-树索引，而不是HASH索引)。是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引、为该部分指定的条件，以及选择的累积函数。有两种方法可以通过索引优化GROUPBY语句：
1，组合操作结合所有范围判断式使用(如果有)。
2，首先执行范围扫描，然后组合结果元组。
Mysql中哪些场景下会导致使用了索引但索引失效，导致性能变差？
以 Mysql 为例，其中索引 BTree 类型 。以下几种SQL设计会导致虽然使用了索引，但是索引不会生效，即引擎放弃使用索引而进行全表扫描：
- WHERE 子句中使用 != 或 <> 操作符。
- WHERE 子句中对索引列使用 %前缀模糊查询。
- WHERE 子句中对索引列使用 OR 来连接条件。
- WHERE 子句中对索引列使用 NOT IN。
- WHERE 子句中对索引列使用计算、函数、类型转换等操作。
- WHERE 子句中对索引列使用参数。
程序员应该都知道，为了提高数据库的查询速度，我们可以对表上的一个字段或者多个字段建立索引，但是有些 SQL 错误的写法，可能会导致索引失效。
01. 查看执行计划
如何判断 SQL 的执行是做了全表扫描还是走了索引，不是凭感觉判断 SQL 执行的快慢，而是要看 SQL 的执行计划；很多工具都提供了查看执行计划的功能，不过最原始的方法，还是通过 explain 进行查看；下面的 SQL，是否使用的索引，一目了然。
1. 没有索引
explain select * from user where gender = 'M';
2. 有索引
explain select * from user where name = 'Tom';
02. 索引失效
1. 使用 like 时，% 在前面不走索引（在后面可以走索引）；
explain select * from user where name like '%om';
2. 数据类型出现隐式转化，比如我们这里手机号 mobile 字段设置的是 varchar 类型，但是查询的时候用的是数字，那么就【可能】不走索引。
explain select * from user where mobile = 13800000000;
3. 在索引字段上使用 not，<>，!= ；
explain select * from user where mobile <> '13800000000';
explain select * from user where mobile != '13800000000';
4. 对索引字段上使用函数；
explain select * from user where length(mobile) < 10
5. 联合索引，如果查询条件不满足最左匹配原则，则不会走索引；
6. or 会使索引失效，尽管 or 左右的条件都有索引；
explain select * from user where name = 'Tom' or mobile = '13800000000';
总之，MySQL 的索引优化和索引失效还是挺复杂的，主要体现在 MySQL 随着版本升级，有一些我们熟知的技巧可能会不再正确，我们现在认为一定会索引失效的 SQL 写法，可能会变成走索引，所以这也是为什么我在上文中，多次用到【可能】会造成索引失效的原因。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。