是的、这是我的个人档案，但是现在还没想好要怎么写🤔

"在我电脑上好好的, 那是你环境有问题, 你是不是不会用"

"这个项目有文档吗?" "忙着呢! 文档有空再写"

// 这里不是bug, 这是一个未标注的特性

// 这段代码我也不知道为什么能运行，但切记，千万不要改动！

在处理海量数据时，我们常常会遇到如何快速判断某个元素是否存在的问题。传统的数据结构，如数组、链表、哈希表等，虽然能解决这个问题，但在面对大规模数据时，它们往往不够高效。布隆过滤器（Bloom Filter）就是为了解决这个问题而诞生的，它能够高效地进行元素存在性的判断，尽管它的判断结果并非百分之百准确。接下来，我们就一起探索布隆过滤器的原理、应用以及如何在实际项目中实现它。

什么是布隆过滤器？

布隆过滤器是一种由二进制位数组和多个哈希函数组合而成的数据结构。它的核心思想是利用多个哈希函数将数据映射到一个位数组中，从而实现快速的查找操作。

布隆过滤器最大的优点是节省空间。当需要存储大量元素时，它比传统数据结构占用更少的内存。然而，它的缺点是误报的可能性存在，这意味着它可能会错误地判断某个元素存在，但绝不会误判某个元素不在。

省流

首先，给出一个大致的结论（完整解释请继续阅读）：

• 有索引时，GROUP BY 和 DISTINCT 的效率几乎相同，都可以利用索引优化。
• 没有索引时，DISTINCT 的效率通常更高。原因在于 GROUP BY 会进行排序，可能会触发 filesort，导致 SQL 执行变慢。

那么，接下来的问题是：

某些情况下，PicGo的插件安装会失败，甚至搜索界面无法使用，此时可以手动安装插件。

1. 找到你所需要要想插件

前边提到，我已经无法搜索插件或插件一直安装失败，所以首先要确认插件的名字，打开插件仓库Plugin for PicGo。 确认你想要的插件，本文以S3为例，他的名字就是picgo-plugin-s3；

作为一个在代码界摸爬滚打多年的码农，我经常被"细节决定成败"这句话折磨。

尤其在软件行业，这句话往往被扭曲成一种近乎宗教式的信仰。你知道那种感觉吗？晚上11点，办公室只剩下你一个人，盯着屏幕上的代码， 仿佛整个公司的命运都系在你的这几行代码上。这种近乎病态的执着，说实话，我也经历过。

这种"细节至上"的心态真的很容易变质。让很多人沉迷于扣细节，却分不清楚什么是充分条件，什么是必要条件。开会的时候，他们絮絮叨叨，浪费大家时间，简直是团队的梦魇。

性能真的那么重要吗？

拿性能来说，其实没那么夸张。即便是支付宝这种面向消费者的服务，用户该用还是会用，根本不在乎那点卡顿。性能确实重要，但绝对不是决定用户去留的关键因素。

说到 SQL 查询语句，几乎所有开发者都对 SELECT * 不陌生。在早期学习 SQL 或快速开发原型时，我们可能经常用它来偷懒，因为它看起来既简单又直接：想要啥，全都给。但随着项目的深入和数据库的复杂化，你会发现这个看似万能的工具，其实问题也不少。

今天我们就来聊聊，为什么在许多开发手册中，明确建议避免使用 SELECT *，以及它为什么仍然在一些场景中大放异彩。

---

为什么不要用 SELECT *

1. 增加不必要的磁盘 I/O