引言 昨天一位公众号粉丝和我讨论了一道面试题，个人觉得比较有意义，这里整理了一下分享给大家，愿小伙伴们面试路上少踩坑。面试题目比较简单：“让你实现一个附近的人功能，你有什么方案？”，这道题其实主要还是考察大家对于技术的广度，本文介绍几种方案，给大家一点思路，避免在面试过程中语塞而影响面试结果，如有不严谨之处，还望亲人们温柔指正！ “附近的人” 功能生活中是比较常用的，像外卖app附近的餐厅，

BATJTMD 等大厂的面试难度越来越高，但无论从大厂还是到小公司，一直不变的重点就是对 SQL 优化经验的考察。一提到数据库，面试官就会问“先说一说你对 SQL 优化的见解吧?”。 图片来自 Pexels SQL 优化已经成为衡量程序猿优秀与否的硬性指标，甚至在各大厂招聘岗位职能上都有明码标注，如果是你，在这个问题上能吊打面试官还是会被吊打呢? 有朋友疑问到，SQL 优化真的有这么重要么?如下图所示，SQL

一、问题起源 不久前用户反馈部门的 MySQL 数据库发生了数据更新丢失。为了解决这个问题，当时对用户使用的场景进行了分析。发现可能是因为用户在两台互为主从的机器上都进行了写入导致的数据丢失。 如图所示，是正常和异常情况下应用写入数据库的示例。随后在更加深入调查问题的过程中，DBA 发现了故障引起数据丢失的原因： 如图 1-2 所示为故障具体过程的还原。从图中可以看出在第 3 步 DP 上的写入操作，在恢复 DA 到 DP 的同步

经常有同学问我，我的一个SQL语句使用了索引，为什么还是会进入到慢查询之中呢？今天我们就从这个问题开始来聊一聊索引和慢查询。 另外插入一个题外话，个人认为团队要合理的使用ORM，可以参考 ORM的权衡和抉择。合理利用的是ORM在面向对象和写操作方面的优势，避免联合查询上可能产生的坑(当然如果你的Linq查询能力很强另当别论)，因为ORM屏蔽了太多的DB底层的知识内容，对程序员不是件好事，对性能有极致追求，但是ORM理解不透彻的团队更加要谨

作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：https://github.com/sunshinelyz/mykit-delay 写在前面 今天，一位哥们打电话来问我说误操作了他们公司数据库中的数据，如何恢复。他原本的想法是登录数据库updat

对于商业数据库而言，数据库升级是一个优先级很高的事情，有版本升级路线图，有相应的补丁，而且对于方案还有一系列的演练，陷入是一场硬仗。而在MySQL方向上，升级这件事情就被淡化了许多，好像只能证明它的存在而已，当然正是由于这种不重视，也让我今天走了不少弯路。 一般来说，升级MySQL有两类可行方案，一类是直接升级数据字典，在本机完成，整个过程会有离线操作，会对业务有中断，第二种是通过高可用切换平滑实现，原理是搭建低版本到高版本的数据复制关

Join并行 Join并行1. 多表join介绍2. 多表Join的方式不使用Join buffer使用Join buffer3. Join执行流程（老执行器） 1. 多表join介绍 JOIN子句用于根据两个或多个表之间的相关列来组合它们。 例如： Orders： Customers： SELECTOrders.OrderID,Customers.CustomerName,Orders.OrderDate FROMOrders IN

介绍 当进行分页时，MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后放弃前 offset 行，返回 N 行。例如 limit 10000, 20。mysql排序取出10020条数据后，仅返回20条数据，查询和排序的代价都很高。那当 offset 特别大的时候，效率就非常的低下，所以我们要对sql进行改写 使用书签 用书签记录上次取数据的位置，过滤掉部分数据 如下面语句 SELECTid,name,desc

日常工作中，总会有因手抖、写错条件、写错表名、错连生产库造成的误删库表和数据的事情发生。但是，如果每次删库都跑路的话，怕是再也不好找工作了吧！所以，删库跑路不是上上策。 1、前言 数据恢复的前提的做好备份，且开启 binlog，格式为 row。如果没有备份文件，那么删掉库表后就真的删掉了，lsof 中还有记录的话，有可能恢复一部分文件。但若刚好数据库没有打开这个表文件，那就只能跑路了。如果没有开启 binlog，那么恢复数据后，从备份时