1、谈谈你在写sql语句需要注意有哪些点？
答：
select * 问题，客户端需要什么，就给什么，不要给多余的字段，这种情况可能还会导致本来可以走覆盖索引的语句不能走覆盖索引。
不要在查询语句字段上做函数运算，这样会让索引失效。
一定要避免mysql自动类型转换，比如 where ‘9’ =9。
能不设置允许 null 的字段尽量不要设置，因为 null 会导致 mysql 多一层判断。
使用 like 的时候如果是通配符 % 在最前面的话也会走的全表扫描。
2、你刚才一直在提索引，把你知道的关于索引的一些技巧说下
答：
要在区分度高的字段上建立索引，否则索引意义不大。
字符串建立索引要注意大小，索引长度过长，占用的空间也就越大，适当的可以截取进行索引，缺点是不能使用到覆盖索引，具体根据业务合理安排。
建立联合索引要知道最左前缀原则，举个例子( name, email, phone ),最终能走这个联合索引的一定只会是 （ name ）,（ name, email )，( name, email, phone )，其他只能走全表，需要根据业务合理设置联合索引的顺序。
3、索引底层是什么数据结构？
答：B+树。
4、为什么用的是B+树，不能使用红黑树或者其他的？
答：可以使用红黑树。但是这样的话可能会造成树的高度过高，意味着相同查询下，会进行更多的磁盘I/O，影响性能，而 B+ 树可以保持树的高度不至于过高。这道题答得不是很好，不仅仅是这样，欢迎补充。
5、你知道索引下推吗？
本质上是对普通索引需要回表的一种优化，也就是引擎层在对索引指针遍历的过程中，先做一些优先的判断，过滤掉不符合条件的，可以减少磁盘IO。
6、假设现在有人操作数据库，不小心执行错了语句，误删除了很多数据，这时候能恢复吗？咋么恢复。
答：首先，一定要开启 bin-log ，如果没有开启的话，可能就恢复不了。要看具体的文件系统是否能恢复。开启了 bin-log ，类型设置要设置成 row 或者 mixed ，不能设置 statement 。然后，如果是误删行的话，就可以把里面对应的删除事件换成插入事件，在备用库上执行。如果是误删表的话，可以先获取最近的一次全量备份，放到备库，然后拿出 bin-log ， 除了不执行删除的事件，其他事件依次重放。
7.为什么不能设置成 statement ？
答：设置成 statement ，实际 bin-log 存储的是 sql 语句（ 非具体删除的主键id ），这样如果是主从架构的话，主和从可能因为选择的索引不一样而导致主从不一致。
8.你刚才说到主从，那你说说主从运行的机制吧
答：首先主库还是要开启 bin-log ， 从库先设置要连接的主库 change master…… 然后执行 start slave，这时候从库会创建两个线程，一个 io_thread ，主要负责连接主数据库。一个sql_thread 主要是负责执行中转日志语句。首先，主库接收到从库的同步请求，根据传递的 bin-log 文件名和开始同步的位置，发送二进制文件给从库，从库 io_thread 负责把接收到的数据放入到中转日志，然后 sql_thread 负责从中转日志读取解析执行，执行完成，更新同步的位置标志。
9.你知道主从延迟吗？有些时候延迟的时间还会很长。遇到这种情况咋么办？
答：这种问题，注意了。划重点。问你出现问题，寻找解决方案的时候，一定要对症下药，也就是说这个问题你可以这样考虑，什么情况下导致的主从延迟。
如果主库和从库服务器配置不一样，从库的差点，那么就可能导致延迟时间加长。这时候，换成相同的服务器配置服务器即可。
从库压力太大了。一般主从了，从库基本用来查询，比如可能运营或者开发者自己都在从库上进行一系列的 sql 操作。那简单呗。多配几个从库，分摊压力，一主多从。
大事务。比如 delete 这种语句 不 limit 限制一下，如果数据量过大，导致主库运行时都花费了长时间，再同步到从库，这个时间间隔过长。
设计模式
你知道哪些设计模式，你平常有使用到吗？可以结合你的业务场景说下吗？
答：先举例平常使用 Laravel，里面就用到大量设计模式，比如门面，组合，装饰，观察者
具体场景带入，然后根据之前业务上的场景说,只有在合适的场景使用合适的模式才能体现它的价值。
网络
1、传输层主要有哪些协议？
答：主要有 TCP 和 UDP 协议。他们的区别是 TCP 是需要连接的 会经过三次握手，而且可以保证消息的可靠性。UDP 是不需要连接的，不保证消息的可靠性。
2、你能大体说说 TCP 的三次握手吗？
答:首先服务器监听某个端口，客户端发起请求 携带syn数据包(第一次)，服务端接收到这个数据包，返回 syn/ack 的数据包给客户端(第二次)，最后客户端再次发送一个 ack 的数据包（第三次)。
3、为什么需要三次握手？
答:主要是为了确认双方接收是否正常。
第一次：客户端什么都不能确认。服务端能确认客户端的发送正常，自己的接收正常
第二次：客户端能确认自己的发送和接收正常，服务端的发送和接收正常。服务端能确认自己接收正常，客户端的发送正常。
第三次：全部都能确认了。
并发
假设现在有多个入口可以同时使用一个账户操作，这个账户只有十块钱，有哪些方法可以使得不超扣消费？开放性题目，只要能解决问题的就是好方案，没有唯一答案。
答：mysql：可以直接 where amount>=current_amount and amount>0 …… , 或者悲观锁 for update。redis:lua 脚本。php 层面可以利用文件锁，还可以使用队列的特性，只有一个消费的出口。
设计
如果我们公司有很多项目都有登录的功能，咋么设计？
答：需要把这个登录单独抽出来作为一个模块开发，类似于登录中心，所有的其他子系统登录都需要从这个系统中认证。
其他
1、看你项目里说到使用过swoole，也写点go，你可以说说他们协程上的区别吗？
答:设计上他们是一样的，主要区别在于，协程调度器模式。swoole 的协程调度器是单线程，go 的协程调度器是多线程。这就意味着，同一时刻 swoole 只有一个协程在运行，而 go 同一时刻可以多个协程在运行。所以在 swoole 协程中不需要对全局变量进行加锁。而且 swoole 本质是单线程多进程的，意味着它没有超全局的变量，仅仅是进程级别变量。而 go 多线程，多线程必然会存在临界变量锁的问题。当然，go 也提供了开箱即用的 sync 读写锁，或者你也可以直接使用通道来代替。
2、你可以说说 go 的 gmp 调度模型吗？
3、说说你们这个项目最难的点是哪个地方，你是咋么解决的？
标签：面试题,从库,协程,高级,索引,go,PHP,主从,客户端 From： https://www.cnblogs.com/haoxuanchen2014/p/17899500.html