目录
可以使用MySQL直接存储文件(ppt,exel,图像等)吗?
如何优化过多join查询关联?Mysql对join查询有什么限制吗?
-
可以使用MySQL直接存储文件(ppt,exel,图像等)吗?
可以使用 BLOB(binary large object),用来存储二进制大对象的字段类型,
- TinyBlob 255 值的长度加上用于记录长度的1个字节(8位)
- Blob 65K值的长度加上用于记录长度的2个字节(16位)
- MediumBlob 16M值的长度加上用于记录长度的3个字节(24位)
- LongBlob 4G 值的长度加上用于记录长度的4个字节(32位)。
-
什么时候存,什么时候不存?
需要高校查询且文件很小时候可以存,但是文件大和数据量变更频发就不建议存,一般来说是不存文件的,因为不好维护,例如一般可以存用户的表情头像url等
-
Emoji乱码怎么办?存储的时候有遇到过什么问题吗?
- 使用utf8mb4存emoji,要不然utf8三字节可能存不下,
- 调整max-allowed-packet来上传大文件、主从同步数据较慢、线程阻塞、占用网络带宽
-
如何存储ip地址?
1.使用字符电
2.使用无符号整型
- 4个字节即解决问题
- 可以支持范围查询
- INET_ATON()和INET_NTOA() ipV6 使用 INET6_ATON() 和 INET6_NTOA()
-
长文本如何存储?
可以使用Text存储
- TINYTEXT(255长度)
- TEXT(65535)
- MEDIUMTEXT(int最大值16M)
- LONGTEXT(long最大值4G)I
-
大段文本如何设计表结构?
1.或将大段文本同时存储到搜索引擎
2.分表存储
3.分表后多段存储
-
大段文本查找时如何建立索引?
1.全文检索,模糊匹配最好存储到搜索引擎中
2.指定索引长度 I
3.分段存储后创建索引
-
有没有在开发中使用过TEXT,BLOB 数据类型
BLOB 之前做ERP的时候使用过,互联网项目一般不用
BLOBTEXT 文献,文章,小说类,新闻,会议内容等
-
日期,时间如何存取?
使用TIMESTAMP、DATETIME
-
TIMESTAMP,DATETIME 的区别是什么?
-
为什么不使用字符串存储日期?
字符串没法完成范围查询操作,在大数据量下查询必须加上时间范围
-
如果需要使用时间戳 timestamp和int该如何选择?
int 存储空间小,运算查询效率高,不受时区影响,精度低
timestamp 存储空间小,可以使用数据库内部时间函数比如更新,精度高,需要注意时区转换,timestamp更易读-般选择timestamp,两者性能差异不明显,本质上存储都是使用的int
-
char与varchar的区别?如何选择?
- char是固定长度255,没有碎片,方便指针操作,数据读取较快,但是会有空间冗余,非固定长度的表使用cha很浪费空间
- varchar是弹性长度,会产生内部碎片,可能磁盘上存储不连续,读取时需要计算下标,时间消耗高,但是节约空间,不浪费空间
财务计算有没有出现过错乱?
- 第一类:锁包括多线程,数据库,展示后超时提交等
- 第二类:应用与数据库浮点运算精度丢失(使用decimal解决)
1.应用开发问题:多线程共享数据读写
2.之前有过丢失精度的问题,使用decimal解决
3.使用乘法替换除法
4.使用事务保证acid特性
5.更新时使用悲观锁 SELECT .. FOR UPDATE
6.数据只有标记删除
7.记录详细日志方便溯源
-
decimal与float,double的区别是什么?
-
浮点类型如何选型?为什么?
- 需要不丢失精度的计算使用DECIMAL
- 仅用于展示没有计算的小数存储可以使用字符串存储·
- 低价值数据允许计算后丢失精度可以使用float double
- 整型记录不会出现小数的不要使用浮点类型
-
预编译sql有什么好处?
服务器通过占位符的方式先预编译一次sql,若每次发送相同的sql都要重新编译就很耗时,使用预编译能达到复用效果,
- 预编译sql会被mysql缓存下来
- 作用域是每个session,对其他session无效,重新连接也会失效
- 提高安全性防止sql注入
- 编译语句有可能被重复调用,也就是说sql相同参数不同在同一session中重复查询执行效率明显比较高
- mysql8 支持服务器端的预编译
-
子查询与join哪个效率高?
join更高,用子查询时都会产生临时表,查询完还有删除的动作,join可以利用索引,所以更快
三种join算法:
Simple Nested-LoopJoin:SNLJ,简单嵌套循环连接。
Index Nested-LoopJoin:INLJ,索引嵌套循环连接。
Block Nested-LoopJoin:BNLJ,缓存块嵌套循环连接
-
join查询可以无限叠加吗?
关联过多会产生更多内存空间,性能下降,最多关联61张表
-
如何优化过多join查询关联?Mysql对join查询有什么限制吗?
- 适当使用冗余字段减少多表关联查询(比如外卖系统,用户的配送地址有很多,此时就可以把默认地址写到主表的一个字段中,不过后续更新时需级联更新主表的地址)
- 驱动表和被驱动表(小表join大表)
- 业务允许的话 尽量使用inner join 让系统帮忙自动选择驱动表
- 关联字段一定创建索引
- 调整JOIN BUFFER大小,主要应用于没走索引的join
-
是否有过mysql调优经验?
调优:
1.sql调优
2.表(结构)设计调优
3.索引调优
4.慢查询调优
5.操作系统调优
6.数据库参数调优
-
开发中使用过哪些调优工具?
-
如何监控线上环境中执行比较慢的sq!?
开启慢查询日志,设置参数long-query-time,记录sql后用MySQL dump slow日志分析工具分析,日志采集完立即关闭慢查询
-
如何查看当前sql使用了哪个索引?
用explain关键字来查看,再具体的就调用优化器的轨迹分析(optimizer-trace)
-
EXPLAIN关键字中的重要指标有哪些?
type是索引查询的类型,rows是返回的行数,filtered是查询的有效率
-
MySQL数据库cpu飙升的话你会如何分析?
看是不是mysql的问题,有没有可能是容器、操作系统的问题(外界因素)
MySQL内部问题:
-
有没有进行过分库分表?
-
什么是分库分表?
-
什么时候进行分库分表?有没有配合es使用经验?
1.能不分就不分
2.单机性能下降明显的时候
3.增加缓存(通常查询量比较大),细分业务4.首先尝试主被集群,读写分离
5.尝试分库
6. 尝试分表->根据业务冷热数据分离,实在不行再分表
大数据量下可以配合es完成高效查询
-
说一下实现分库分表工具的实现思路
1.伪装成mysql服务器,代理用户请求转发到真实服务器(MyCat工具)
2.基于本地aop实现,拦截sql,改写,路由和结果归集处理。ShardingSphere
-
用过哪些分库分表工具?
-
分库分表后可能有哪些问题?
1.执行效率明显降低
2.表结构很难再次调整
3.引发分布式id问题
4.产生跨库join
5.代理类中间件网络io成为瓶颈
-
读写分离常见方案
主被数据同步,写多读少 ,现在都由mycat自主分配实现,我们只用面向mycat一台服务器
-
为什么要使用视图?什么是视图?
表结构复杂,关联较多,如果查询的一些数据较为频繁,可以将其存储成一个视图
-
什么是存储过程?有没有使用过?
存储过程现在一般不适用,全放在代码层面解决,因为难以调试和扩展,
-
有没有使用过外键?有什么需要注意的地方?
同上,一般不使用,难以维护
-
用过processlist吗?
查看MySQL的会话,一般用于调优:
-
某个表有数干万数据,查询比较慢,如何优化?说一下思路
- 1.前端优化
1.合并请求:多个请求需要的数据尽量一条sql拿出来2.会话保存:和用户会话相关的数据尽量一次取出重复使用
3.避免无效刷新
- 2.多级缓存,不要触及数据库。
1.应用层热点数据高速查询缓存(低一致性缓存)
2.高频查询大数据量镜像缓存(双写高一致性缓存),比如用30G的redis集群存储
3.入口层缓存(几乎不变的系统常量)
- 3.使用合适的字段类型,比如varchar换成char
- 4.一定要高效使用索引。
1.使用explain 深入观察索引使用情况
2.检査select 字段最好满足索引覆盖
3.复合索引注意观察key_len索引使用情况
4.有分组,排序,注意file sort,合理配置响应的buffer
- 5.检査查询是否可以分段查询,避免一次拿出过多无效数据
- 6.多表关联查询是否可以设置冗余字段,是否可以简化多表查询或分批查询
- 7.分而治之:把服务拆分成更小力度的微服务
- 8.冷热数据分库存储读写分离,主被集群
-
count(列名)和count(*)有什么区别
count(列名)一列空值NULL不计数,count(*)null也统计
-
超大分页怎么处理
-
mysql服务器毫无规律的异常重启如何排查问题?
-
mysql 线上修改表结构有哪些风险?
-
什么是mysql多实例部署?
同一个服务器上安装多个MySQL,压榨服务器剩余性能,缺点是互相影响,同时跑多个mysql,但可能影响其他进程,最好是容器化管理,要不然容易出问题,现在也很少用到多实例部署
标签:知识点,面试题,join,MySQL,存储,查询,索引,使用,分表 From: https://blog.csdn.net/qq_51586702/article/details/137117425