大家好,我是陈哈哈,北漂五年。相信大家和我一样,
都有一个大厂梦
,作为一名资深Java选手,深知面试重要性,接下来我准备用100天时间,基于Java岗面试中的高频面试题,以每日3题
的形式,带你过一遍热门面试题及恰如其分的解答。
一路走来,随着问题加深,发现不会的也愈来愈多。但底气着实足了不少,相信不少朋友和我一样,日积月累才是最有效的学习方式!想起高三时一个同学的座右铭:只有沉下去,才能浮上来。
共勉(juan)。
坐标:美丽的乌兰察布
作者:Mᴀʀᴄʜ
本栏目Java开发岗高频面试题主要出自以下各技术栈:Java基础知识
、集合容器
、并发编程
、JVM
、Spring全家桶
、MyBatis等ORMapping框架
、MySQL数据库
、Redis缓存
、RabbitMQ消息队列
、Linux操作技巧
等。
当 cpu 飙升到 500%时,先用操作系统命令 top 命令观察是不是 mysqld 占用导致的,如果不是,找出占用高的进程,进行相关处理。
如果是 mysqld 造成的, show processlist
,看看里面跑的 session 情况,是不是有消耗资源的 sql 在运行。找出消耗高的 sql,看看是没用上索引
还是IO过大
造成的。
mysql> show processlist; +--------+-----------------+--------------------+---------+---------+------+-----------------------------+------------------+ | Id | User | Host | db | Command | Time | State | Info | +--------+-----------------+--------------------+---------+---------+------+-----------------------------+------------------+ | 1 | event_scheduler | localhost | NULL | Daemon | 313 | Waiting for next activation | NULL | | 239896 | root | 192.168.1.21:55050 | finance | Sleep | 1160 | | NULL | | 239898 | root | 192.168.1.21:58118 | NULL | Sleep | 397 | | NULL | | 239899 | root | 192.168.1.21:58127 | csjdemo | Sleep | 393 | | NULL | | 239901 | root | 192.168.1.21:58135 | csjdemo | Sleep | 387 | | NULL | | 239901 | root | 192.168.1.21:58135 | csjdemo | Query | 1044 | | select * from T like `name` like '%陈哈哈%' | | 239904 | root | localhost | NULL | Query | 0 | starting | show processlist | +--------+-----------------+--------------------+---------+---------+------+-----------------------------+------------------+ 6 rows in set (0.00 sec)
show full processlist
可以看到所有链接的情况,但是大多链接的 state 其实是 Sleep 的,这种的其实是空闲状态,没有太多查看价值;我们要观察的是有问题的,所以可以进行过滤:
-- 查询非 Sleep 状态的链接,按消耗时间倒序展示,自己加条件过滤 select id, db, user, host, command, time, state, info from information_schema.processlist where command != 'Sleep' order by time desc
mysql> select id, db, user, host, command, time, state, info from information_schema.processlist where command != 'Sleep' order by time desc \g; +--------+------+-----------------+-----------+---------+------+-----------------------------+---------------------------------------------+ | id | db | user | host | command | time | state | info | +--------+------+-----------------+-----------+---------+------+-----------------------------+---------------------------------------------+ | 1 | NULL | event_scheduler | localhost | Daemon | 515 | Waiting for next activation | NULL | | 239904 | NULL | root | localhost | Query | 1044 | executing | select * from T like `name` like '%陈哈哈%' | +--------+------+-----------------+-----------+---------+------+-----------------------------+---------------------------------------------+ 2 rows in set (0.00 sec)
这样就过滤出来哪些是正在干活的,然后按照消耗时间倒叙展示,排在最前面的,极大可能就是有问题的链接了,然后查看 info
一列,就能看到具体执行的什么 SQL 语句了,针对分析。
一般来说,要 kill 掉这些线程(同时观察 cpu 使用率是否下降),等进行相应的调整(比如说加索引
、改 sql
、改内存参数
)之后,再重新跑这些 SQL。
也有可能是每个 sql 消耗资源并不多,但是突然之间,有大量的 session 连进来导致 cpu 飙升,这种情况就需要跟应用一起来分析为何连接数会激增,再做出相应的调整,比如说限制连接数
等。
课间休息,又来秀一下来自咱们群里同学的搬砖工地,坐标:???。
作者:云野
存储过程(Procedure)是一条或多条预编译的SQL语句
,一组为了完成特定功能的SQL 语句集
,它存储在数据库中,一次编译后永久有效,用户通过指定存储过程的名字并给出参数(如果该存储过程带有参数)来执行它。
优点
在数据库中集中业务逻辑
使数据库更安全
较快的执行速度
Transaction-SQL
代码或分别被多次执行,那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译
的。在首次运行一个存储过程时查询,优化器对其进行分析优化,并且给出最终被存储在系统表中的执行计划。而批处理的Transaction-SQL语句在每次运行时都要进行编译和优化,速度相对要慢一些。缺点
不可移植性
复杂存储过程消耗资源多
每个连接的内存使用量可能将大大增加
,执行时间也会很长,要有所准备。故障排除难
维护成本高
普通业务逻辑尽量不要使用存储过程,定时性的ETL任务
或报表统计
函数可以根据团队资源情况采用存储过程处理。存储过程可以快速解决问题,但是移植性、维护性、扩展性不好
,它有时会约束软件的架构,约速程序员的思维,在你的系统没有性能问题时不建议用存储过程。如果你要完成的功能只是一次或有限次的工作,如数据订正、数据迁移等等,存储过程也可以拿上用场。
如果你的系统很小,并且有50%的开发人员熟练掌握PL/SQL,人员结构稳定,那存储过程可以减少很多代码量,并且性能不错。当系统变复杂了,开发人员多了,存储过程的弊端就会呈现,这时你需要痛下决心了。
课间休息,又来秀一下来自咱们群里同学的搬砖工地,坐标:赣州。
作者:胡巴
答案参考林晓斌的MySQL实战45讲
如果业务代码已经保证了不会写入重复的身份证号
,那么这两个选择逻辑上都是正确的
。如果从效率上讲,主要关注点还是在SELECT和UPDATE操作上;
对于一条SELECT查询来说:
假设,执行查询的语句是 select id from T where id=5。这个查询语句在索引树上查找的过程,先是通过 B+ 树从树根开始,按层搜索到叶子节点,然后取出该叶子节点所在的数据页
(先判断changebuffer内存中是否有该页,没有就先从磁盘中读到内存),最后通过二分法在数据页中定位id=5的行数据。
这两者性能差距会有多少呢?微乎其微
。对于普通索引,因为本身就是以数据页为单位读进内存,数据页大小默认16KB(大概1000行),要多做的那一次“查找和判断下一条记录”的操作,就只需要一次指针寻找和一次计算
。
对于一条UPDATE查询来说:
当需要更新一个数据页时,如果数据页在内存中就直接更新,而如果这个数据页还没有在内存中的话,在不影响数据一致性的前提下,InnoDB 会将这些更新操作缓存在 change buffer 中
,这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候
,将数据页读入内存,然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。需要说明的是,虽然名字叫作 change buffer,实际上它是可以持久化的数据
。也就是说,change buffer 在内存中有拷贝,也会被写入到磁盘上。
将 change buffer 中的操作应用到原数据页,得到最新结果的过程称为merge
。除了(SELECT)访问这个数据页会触发 merge 外,系统有后台线程会定期 merge
。在数据库正常关闭(shutdown)的过程中,也会执行 merge 操作。
显然,如果能够将更新操作先记录在 change buffer
,减少读磁盘,语句的执行速度会得到明显的提升。而且,数据读入内存是需要占用 buffer pool 的,所以这种方式还能够避免占用内存,提高内存利用率
。
那么,什么条件下可以使用 change buffer 呢?对于唯一索引
来说,所有的更新操作都要先判断这个操作是否违反唯一性约束
。比如,要插入 id=5 这条记录,就要先判断现在表中是否已经存在 id=5 的记录,而这必须要将数据页读入内存才能判断
。如果都已经读入到内存了,那直接更新内存会更快,就没必要使用 change buffer 了。
因此,唯一索引的更新就不能使用 change buffer
,实际上也只有普通索引可以使用
。
change buffer 用的是 buffer pool 里的内存,因此不能无限增大。change buffer 的大小,可以通过参数 innodb_change_buffer_max_size 来动态设置。这个参数设置为 50 的时候,表示 change buffer 的大小最多只能占用 buffer pool 的 50%
。
那么如果要在这张表(id,name)中插入一个新记录 (5,“陈哈哈”) ,InnoDB 的处理流程是怎样的呢?
第一种情况是,这个记录要更新的目标页在内存中。这时,InnoDB 的处理流程如下:
第二种情况是,这个记录要更新的目标页不在内存中。这时,InnoDB 的处理流程如下:
将数据从磁盘读入内存涉及随机 IO
的访问,是数据库里面成本最高的操作之一
。change buffer 因为减少了随机磁盘访问,所以对更新性能的提升是会很明显的。
之前我就碰到过一件事儿,有个 DBA 的同学跟我反馈说,他负责的某个业务的库内存命中率突然从 99% 降低到了 75%,整个系统处于阻塞状态,更新语句全部堵住。而探究其原因后,我发现这个业务有大量插入数据的操作,而他在前一天把其中的某个普通索引改成了唯一索引。
今天我们复习了面试中常考的数据库相关的三个问题,你做到心中有数了么?对了,如果你的朋友也在准备面试,请将这个系列扔给他,如果他认真对待,肯定会感谢你的!!
好了,今天就到这里,学废了的同学,记得在评论区留言:打卡。
,给同学们以激励。