最近一个月，这里发布这个想法的，看见过都快 5 次了。

我在浦东商城路那边一家第三方店修过多年了，还不错，
2014 年给 2009 版 MacBook 13 寸换过显示屏，那时 700 块。

后来也陆续去修过几台 iPhone，算靠谱，2013-2014 年那家店被 Apple China 官网的(合作)维修点列表收录过。

需要了解，可以 Telegram / Twitter 我(个人资料页)

技术类...代码排版不乱，那么 影印版 pdf / 影音图片了吧。

Swift 官方手册 iBook 版依稀记得效果还是蛮好的。

[历史记录表需要在 4 个 int 字段上做筛选] 历史记录筛选，这个是不是交由 hadoop 来作个 mapreduce 会更好?

老生常谈提示下：得用 InnoDB

不写博客，就写几个页面吧，页面可以在线增删改查的。

PostgreSQL 性能优化方法 - 1-博客-云栖社区-阿里云 : https://yq.aliyun.com/articles/214

发现这个博客，PG 相关还有好几篇

Greenplum 是基于 PostgreSQL 的并行计算版本，假若单机 DB 还不能满足，可以尝试用它

mysql, postgresql 都有内置的 benchmark 基准测试功能，可以用这个测试作对比

@yejinmo [配置使用默认] MySQL ? PostgreSQL ?

MySQL 使用默认，尤其 InnoDB 使用默认，则极大影响性能。

@yejinmo 你这台机是 SSD 么？换用 SSD 对 DB 的效能提升简直就是银子弹。

@yejinmo

count(*) 是比较特别的需求（我那时就是需要这个)，对你参考价值有限，建议你直接装一个 PG 载入数据实际测测看。

这个测试里 postgresql 没有作特殊优化，debian 下直接 apt-get 装完就测试。

MySQL 是作了优化，设置了 InnoDB MEM Pool 为内存一半，其他相关优化也做过。

对了，MyISAM 类型表，count(*) 是直接返回数值，没有实际查询耗时(因为它对这个操作设计记得就是删改记录时维护一个计数器，count()直接返回数值)。MyISAM 不支持事务，只有表级锁，没有全文索引，表特别容易坏，只适合纯查询，Innodb 这些年性能也提高很多了，一般也没人用 MyISAM 了。

翻到笔记, 2013 年前做过对比测试，同一软硬件环境，非常简单的单表，180 万行:

postgres=# select count(*) from status;
count
---------
1841495
(1 row)

Time: 516.717 ms

mysql Innodb 表：

mysql> select count(*) from status;
+----------+
| count(*) |
+----------+
| 1841495 |
+----------+
1 row in set (3.53 sec)

表结构:

| status | CREATE TABLE `status` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`date` date NOT NULL,
`license` varchar(100) NOT NULL,
`localdomain` varchar(100) NOT NULL,
`mailing` varchar(50) NOT NULL DEFAULT 'unknown',
`isp` varchar(50) NOT NULL,
`success` int(50) NOT NULL,
`spamrelay` int(50) NOT NULL,
`overlimit` int(50) NOT NULL,
`badmailbox` int(50) NOT NULL,
`timeexpired` int(50) NOT NULL,
`unknown` int(50) NOT NULL DEFAULT '0',
`open` int(50) NOT NULL DEFAULT '0',
`click` int(50) NOT NULL DEFAULT '0',
`olapstamp` char(19) NOT NULL DEFAULT '0000-00-00 00:00:00',
`updatestamp` char(19) NOT NULL DEFAULT '0000-00-00 00:00:00',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1911671 DEFAULT CHARSET=utf8 |
+--------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

@gamecreating
@greatbody
@doomzc

体积缩小了，质量也要减小吧？否则可能密度太大击穿口袋路面地壳...

@Feiox 人家底层硬件可能都是以百万为单价的...

买过手表那种静电消除器，真的管用，就是体积大，样子丑。

工作资历长短，和能力并不能直接划等号，职场里这是常识了吧。

@honeycomb 也对，存储这么重要的用途，服务器上一般是没人敢用不带冗余的配置。

@honeycomb 那么看来路子没错，自动修复数据错误，前提必须是存储池 /卷 底层必须是带冗余的才可以。这和 ZFS 的作法一样的。

@honeycomb [refs 会自行丢掉错误数据，美其名曰数据打捞]

貌似是想抄 带冗余的 ZFS 池的“数据自动错误修正”，看起来是实现错了方向。