mysql中orderby的用法

老实说，我遇到的陷阱比我在使用 MySQL ORDER BY 时学到的还要多。
以多列排序为例。
一旦我编写了订单报告并按金额降序对它们进行排序。
结果发现，相同金额的订单是按照下单时间升序排列的。
终于，报告前面挤满了一堆奇怪的信息。
那一刻我真的哭笑不得。

有趣的是 NULL 值的处理。
我刚加入这个行业的时候就被骗了。
客户要求将未填写年龄的用户显示在前面。
结果，默认的 NULL 最小值将所有这些用户推送到第一行，导致报告逻辑变得一团糟。
然后，使用COALESCE(age, '0')，指定NULL算为0，将这群看不见的人排到最后。

说到排序表达式，我最近在创建活动报表时使用了它。
按用户级别排序，但级别是一个整数字段。
直接使用ORDER BY级别会导致所有VIP用户最终都被压扁，因为数字排序是基于ASCII码的。
切换到CASE WHEN...END后，结果就更清晰了。
但当时我不太明白，为什么MySQL的表达式排序优化这么别扭。

在性能优化方面，我有血泪的教训。
当我给一个大表添加索引后，我发现排序性能不但没有提高，反而变慢了。
后来检查执行计划，发现虽然查询使用了结束索引，但索引中并没有包含需要排序的列，所以只好回表取数据。
我记得这段数据是关于
其实使用ORDER BY时最关键的就是理解数据的分布。
比如，我按照部门排序后，发现某个部门的员工太多了，所以我就按照部门名称的字母顺序排序。
最终，这份报告被这个大部门彻底压垮了。
然后，通过部门ID排序解决了问题。
我自己没有这样做过，但逻辑应该是类似的。

功能处理需要特别注意。
有一次我用UPPER(name)排序，本来以为大写字母会放在第一个位置，结果发现索引直接失败了，整个查询从秒变成了分钟。
当时真的很混乱，我最终转而使用 WHERE IS NOT NULL AND name != '' 并且这种条件组合几乎没有得到维护。
说实话，优化MySQL函数的处理可能是我多年来在这个行业的经历中最不合理的部分。

不过话虽如此，如果控制表达式开销并很好地使用索引和 LIMIT，ORDER BY 还是相当有效的。
比如我曾经在电商后台添加了“最近交易订单”功能，使用ORDER BY order_time DESC LIMIT 1 0，每次取1 0条最近订单，既满足了需求，又保证了速度。
在这种情况下，ORDER BY 只是一个神奇的工具。

mysql中union的用法

说白了，MySQL 中使用 UNION 将多个 SELECT 查询的结果集合并为一个。
其实很简单：只需将几个 SELECT 语句放在一起即可，但它们的长度必须相似。
例如，列数必须一致，数据类型必须兼容。

我们先来说说最重要的事情。
默认情况下，UNION 会删除重复项。
这意味着如果有两条相同的记录，则仅显示一条。
这让我们去年做的项目差点就遇到了麻烦。
我们原本想保留重复项，但最终使用了 UNION 的标准重复数据删除机制，并在此过程中丢失了一些关键数据。
还有一点：如果你想保留所有记录，包括重复的记录，请使用UNION ALL。

另一个关键细节是 ORDER BY 只能在 UNION 末尾使用，而不能在每个 SELECT 语句之后使用。
例如，您不能在第一个 SELECT 之后编写 ORDER BY，然后在第二个 SELECT 之后再次编写。
起初我以为这样很好，但后来我发现这是错误的。
我必须记住，最终我只能使用它一次。

等等，还有别的事。
UNION和JOIN虽然可以合并数据，但是它们的用法是不同的。
UNION是垂直合并，增加行数，JOIN是水平合并，增加列数。
例如，UNION用于合并不相关的数据，JOIN用于查找相关数据。

最后提醒一下：如果使用UNION，数据集可能会变慢，因为UNION需要额外的步骤来删除重复项。
很多人不注意这一点。
我认为值得一试。
如果需要保留所有数据，即使是重复的，优先考虑UNION ALL。

mysql中limit的用法

记得有一次，我在开发一个电商网站的产品展示功能时，遇到了一个头疼的问题。
用户想要浏览商品，但每次加载整个商品列表时，页面加载缓慢，用户体验极差。
当时我就想：有没有办法只上传部分产品呢？
后来查资料，发现了MySQL中的LIMIT子句。
我想测试一下，所以我写了一个简单的查询语句，只返回前 1 0 条产品记录。
结果出奇的好，页面加载速度明显加快，用户体验也得到改善。

这个小小的改变让我认识到 LIMIT 子句在处理大量数据时的威力。
不过，我也遇到了一些问题，比如LIMIT不能与GROUP BY、DISTINCT或HAVING一起使用，这迫使我重新设计查询语句。
另外，太大的偏移量会影响性能，所以我学会了使用索引列过滤来优化查询。

现在，每当我发现自己处于需要在页面上显示数据的情况时，我总是会想到该电子商务网站的历史以及 LIMIT 子句为我提供的便利。
等等，我突然想到，如果LIMIT子句和JOIN操作一起使用会怎么样？