大家好，我是陈哈哈，北漂五年。相信大家和我一样，
都有一个大厂梦，作为一名资深Java选手，深知面试重要性，接下来我准备用100天时间，基于Java岗面试中的高频面试题，以每日3题的形式，带你过一遍热门面试题及恰如其分的解答。
一路走来，随着问题加深，发现不会的也愈来愈多。但底气着实足了不少，相信不少朋友和我一样，日积月累才是最有效的学习方式！想起高三时一个同学的座右铭：只有沉下去，才能浮上来。共勉（juan）。
工地坐标：上海某写字楼
作者：maybe
车票
- 面试题1：有个需求需要快速删除MySQL表中一亿条数据，表中有2亿数据，能说一下你的思路么？
- 面试题2：刚才你提到了逻辑删除，你是怎么看逻辑删除和物理删除的？
- 面试题3：大型项目中，mysql的主键需要全局唯一怎么办？
- 每日小结
本栏目Java开发岗高频面试题主要出自以下各技术栈：Java基础知识、集合容器、并发编程、JVM、Spring全家桶、MyBatis等ORMapping框架、MySQL数据库、Redis缓存、RabbitMQ消息队列、Linux操作技巧等。
面试题1：有个需求需要快速删除MySQL表中一亿条数据，表中有2亿数据，能说一下你的思路么？
我们知道MySQL删除数据的方式有多种比如DELETE、TRUNCATE、DROP等，都属于物理删除，但在实际场景中，很多时候是不能直接用的。
比如咱们说的这张表中有2亿条数据，要删其中1亿条，以InnoDB引擎为例，直接加WHERE条件DELETE是不现实的，因为DELETE是一条一条删，要把操作记录到binlog日志（前提开启了binlog），删除少量数据还可以，删除1亿条会非常慢，并且不会释放出磁盘空间，还得用optimize或repair来压缩数据表来释放硬盘空间。如果字段内容多，IO成本很高，CPU各种过高，耗时更长，不可行。
如果我用truncate删数据，速度倒是很快，能直接释放磁盘空间，但这是全表数据删除，直接清空数据文件或分区磁盘空间，剩下不用删的1亿条又怎么办呢？
因此我们要根据实际情况入手，比如表中有2亿条数据，要删其中1亿条；
-
方法一：着急的话，可以临时使用逻辑删除，选一个字段或加一个字段如is_deleted，作为逻辑删除标志，然后通过该字段过滤后继续处理数据，等到夜深人静。。。 -
方法二：可以新建一张表结构一致的表，把不用删除的数据导进去，然后drop原表，再把新表名称改为原表名称；这是一种比较常见的方式，要注意的是，如果索引较多或索引字段较大的话，记得先导数据，再加索引，别问我为什么。
我们简单看一下方法二的操作流程：
1、复制表+删除索引
create table new_T like T;
ALTER TABLE new_T DROP INDEX index_name1;
ALTER TABLE new_T DROP INDEX index_name2;
2、插入数据要分批插入，建议为10w-50w一次，根据你的MySQL服务器性能来定，可以按ID查询后插入，也可以null as id按新顺序插入。如：
insert into new_T (select null as id,col1,col2,col3 from T where id>500000 and id<=600000);
insert into new_T (select null as id,col1,col2,col3 from T where id>600000 and id<=700000);
...
3、drop删除掉老表
drop table T;
4、重命名新表为new_T
alter table new_T rename to T;
课间休息，又来秀一下来自咱们群里同学的搬砖工地，坐标：？？。
作者：if you
面试题2：刚才你提到了逻辑删除，你是怎么看逻辑删除和物理删除的？
我理解物理删除指的将数据从磁盘中真实删除，而逻辑删除则是在代码层面的，多是将删除数据行的is_deleted字段置成1，后续只操作is_deleted=0的那些未被删除的数据。
在严谨的开发环境中，实际上是没有删除这一说的。订单作废，用户禁用，优惠券作废都是状态的变化，而不应该让数据从磁盘消失。所以 SQL 里面 DELETE 在真实生产环境里都不应该出现，除DBA账号外的其他用户不应有DELETE、TRUNCATE、DROP权限，而只有UPDATE权限。
我还见过有单位将MySQL的update命令封装成删除命令的~~然后用户只能看到表中或视图中is_deleted=0的数据，好像是实现了权限隔离，其实就是闲的慌。
当然了，逻辑删除其实也是有问题的，逻辑删除的设计还会导致常用的unique key 失效；脏数据量大的时候研发人员可能会发现表中明明数据不多，但检索速度很慢，可能会误导研发人员的维护工作。
课间休息，来看一下来自咱们群里同学旅游拍摄的，坐标：日本。
作者：胡巴
面试题3：大型项目中，mysql的主键需要全局唯一怎么办？
在只使用单数据库时，使用自增主键ID无疑是最适合的。但在集群、主从架构上时就会有一些问题，比如怎么做到主键的全局唯一。
使用UUID
这时我们首先想到的解决方法可能是以UUID为主键，对于InnoDB这种聚集主键类型的引擎来说，数据会按照主键进行排序，由于UUID的无序性，InnoDB会产生巨大的IO压力，此时不适合使用UUID做物理主键，但可以把它作为逻辑主键，物理主键依然使用自增ID。
另外，innodb会对主键进行物理排序，这对auto_increment_int是个好消息，因为后一次插入的主键位置总是在最后。但是对uuid来 说，这却是个坏消息，因为uuid是杂乱无章的，每次插入的主键位置是不确定的，可能在开头，也可能在中间，在进行主键物理排序的时候，势必会出现大量 IO操作影响效率。
使用自增ID
方法一：比如4台数据库，第一台mysql主键从1开始每次加4，第二台从2开始每次加4，以此类推。这里的4代表数据库总量，我们叫它步长，从而保证主键的全局唯一，我们需要保证的就是确保自增 ID 起始点（auto_increment_offset）以及 ID 自增步长（auto_increment_increment）的正确性即可。
修改MySQL默认自动增长的步长
-- 设置序列的增长值
set global auto_increment_increment=1;
方法二：通过集群编号加集群内的自增（auto_increment类型）两个字段共同组成唯一主键。优点是实现简单，维护也比较简单，对应用透明。缺点是引用关联操作相对比较复杂，需要两个字段，主键占用空间较大，在使用 InnoDB 的时候这一点的副作用很明显（但是这方式仅仅多了一个smallint两个字节，100W也就多2M）。
每日小结
今天我们复习了面试中常考的数据库相关的三个实际问题，你做到心中有数了么？对了，如果你的朋友也在准备面试，请将这个系列扔给他，如果他认真对待，肯定会感谢你的！！好了，今天就到这里，学废了的同学，记得在评论区留言：打卡。，给同学们以激励。