多篇SQL性能优化文章、仿贝壳App全景看房 | 酱酱的下午茶第158期
今日主理人｜下午茶
每日干货｜下午茶
主理人们会对近期（1-3 天）社区深度技术好文进行挖掘和筛选，优质的技术文章有机会出现在下方列表，排名不分先后。
『前端』
omit的实现与库的快速搭建
用js实现一个网页版节拍器
用前端三剑客实现烟花
跨域是前端开发中一个非常常见的问题，尤其是随着单页应用（Single Page Application, SPA）的兴起，前后端分离开发和部署，前端在本地开发和部署的过程中都会面临着跨域问题。我们再次聊聊跨域这个话题，以及项目中对跨域的一些实践经验，希望带来一些新的收获。
首先就是对贝壳看房app进行分析。进来 app 首页点击下方的 Tabber 标签栏就能实现页面的切换；于是就决定将这五个页面写成五个不同的路由，将这些路由进行集中的管理。每个页面里面的内容进行组件式的封装用不同的路由地址展示组件的内容，再引用到该页面上，大致思路就是这样。
『后端』
发明SQL的初衷之一显然是为了降低人们实施数据查询计算的难度。SQL中用了不少类英语的词汇和语法，这是希望非技术人员也能掌握。确实，简单的SQL可以当作英语阅读，即使没有程序设计经验的人也能运用。
然而，面对稍稍复杂的查询计算需求，SQL就会显得力不从心，经常写出几百行有多层嵌套的语句。这种SQL，不要说非技术人员难以完成，即使对于专业程序员也不是件容易的事，常常成为很多软件企业应聘考试的重头戏。三行五行的SQL仅存在教科书和培训班，现实中用于报表查询的SQL通常是以“K”计的。
今天，我们在这里不展开说明这些问题，而是跟大家介绍在这些优化的层面中，有哪些是优化对 MySQL 数据库来说作用微乎其微，以便我们在产生环境中调优 MySQL 数据库时，避免一些不必要的优化。
业务发展初期，数据库中量一般都不高，也不太容易出一些性能问题或者出的问题也不大，但是当数据库的量级达到一定规模之后，如果缺失有效的预警、监控、处理等手段则会对用户的使用体验造成影响，严重的则会直接导致订单、金额直接受损，因而就需要时刻关注数据库的性能问题。
RPC框架泛化调用功能在网关、接口测试等场景下有着广泛的需求，本文给各位读者介绍一下主流的泛化调用实现方式及原理，比较各种实现方案的优缺点，并分享泛化调用在转转的实践。一方面有助于RPC框架使用方理解泛化调用，更好地使用泛化调用；另一方面对于有自研RPC框架需求的开发者在选择泛化调用实现方案上有一定参考意义。
文章最开始先给大家两条sql，请猜猜他们执行会有什么区别？
SELECT * from student s where age < 17 and name ='zhangsan12' and create_time < '2023-01-17 10:23:08' order by age LIMIT 1
SELECT * from student s where age < 17 and name ='zhangsan12' and create_time < '2023-01-17 10:23:08' order by age LIMIT 2
这两条sql看似只是limit的数值不同，但是第一个执行耗时3ms，第二个执行耗时66s，相差2000多倍。
今天要讲的这件事和上述的两个sql有关，是数年前遇到的一个关于
MySQL查询性能的问题。主要是最近刷到了一些关于MySQL查询性能的文章，大部分文章中讲到的都只是一些常见的索引失效场合，于是我回想起了当初被那个离奇的“索引失效”支配的恐惧。
📖 投稿专区｜下午茶
大家可以在评论区推荐认为不错的文章，并附上链接和推荐理由，有机会登上下一期。文章创建日期必须在近 1-3 天内；可以推荐自己的文章、也可以推荐他人的文章。