MySQL DB
2020-08-12
| 字段 |
MySQL 数据类型 |
备注 |
| 用户 ID |
INT UNSIGNED |
- |
| 用户名称 |
VARCHAR(255) |
按需调整长度 |
| 年龄 |
TINYINT UNSIGNED |
0 - 255 |
| 性别 |
ENUM('男', '女') |
若性别选项较多,可改用 VARCHAR 😂 |
| 国家地区 |
VARCHAR(100) |
或使用 ISO 3166 国家代码(CHAR(4)) |
| 电话号码 |
VARCHAR(20) |
可包含符号(如 +、-)和空格(考虑加密存储) |
| URL |
VARCHAR(2083) |
- |
| Email 地址 |
VARCHAR(255) |
配合正则验证(考虑加密存储) |
| IP 地址 |
VARBINARY(16) |
INET_ATON / INET_NTOA / INET6_ATON / INET6_NTOA |
| APIKey |
VARCHAR(255) |
加密 / 哈希后的密钥 |
| 雪花 ID |
BIGINT UNSIGNED |
- |
| 日期 |
DATE |
日期 |
| 时间 |
TIME |
时间(不含日期) |
| 日期时间 |
DATETIME |
如需考虑时区,统一转换成 UTC / 北京时间存储 |
| 时间戳 |
TIMESTAMP |
无时区问题,且存储空间小(如果可以忽略 2038 问题) |
| 年 |
YEAR |
1 字节,1901 - 2155 |
| 状态 |
TINYINT |
- |
关于状态,个人偏好使用 TINYINT
| 数据类型 |
优点 |
缺点 |
备注 |
| ENUM |
可读性 + 存储高效 |
拓展性差(增加类型需要改表) |
适合修改频率极低 |
| TINYINT |
存储高效 |
可读性差 |
- |
| VARCHAR |
可读性 |
存储效率低 |
- |
存储 IP(IPv4 32 位 / IPv6 128 位)的常见方案
| 数据类型 |
存储空间(IPv4) |
存储空间(IPv6) |
可读性 |
查询效率 |
| char / varchar |
15 |
39 |
高 |
低 |
| unsigned int |
4 |
不支持 |
低 |
高 |
| binary / varbinary |
4 |
16 |
低 |
高 |
常见操作:排序,按网段查询
- char 可读但低效,即便去掉小数点,每一段对齐到 3 位,IPv4 也需要 12 字节(牺牲可读性)
- int 的问题是无法支持 IPv6
存储日期时间的常见方案
- 仅需日期时用
DATE(3 字节),仅需年份时用YEAR(1 字节)。
- 格式:
- 无时区: 2025-06-17 15:30:00
- ISO 8601: 2025-06-17T15:30:00+08:00
- 精度:秒,毫秒,微秒,纳秒
- 普通业务(如订单时间)用秒级(
DATETIME/TIMESTAMP);
- 金融交易、性能监控需毫秒/微秒级(
DATETIME(3)/BIGINT)。
- 2038 问题:1970-01-01 00:00:01.000000 ~ 2038-01-19 03:14:07.499999
- 截止到最新的 8.0 版本,TIMESTAMP 类型的 2038 年问题依然没有解决。
- MySQL 5.6+ 支持 datetime / timestamp 带小数位,最多支持 6 位小数(微秒级)
| 数据类型 |
大小 |
精度 |
时间范围 |
描述 |
| DATETIME |
8 字节 |
秒级 |
1000 - 9999 |
- |
| DATETIME(n) |
8+2n 字节 |
微秒级 |
1000 - 9999 |
n 表示小数位(0 ~ 6),毫秒:n = 3 |
| TIMESTAMP |
4 字节 |
秒级 |
1970 - 2038 |
按 UTC 时间存储,查询时自动转换时区,存在 2038 问题 |
| TIMESTAMP(n) |
4+2n 字节 |
微秒级 |
1970 - 2038 |
支持毫秒/,存在 2038 问题 |
| UNSIGNED INT |
4 字节 |
秒级 |
1970 - 2038 |
和 timestamp 一致,存在 2038 问题 |
| UNSIGNED BIGINT |
8 字节 |
毫秒级 |
♾️ |
无溢出风险 |
| CHAR(19) |
19 字节 |
任意 |
♾️ |
YYYY-MM-DD HH:MM:SS,可读但低效 |
| VARCHAR(25) |
25 字节 |
任意 |
♾️ |
2025-06-17T15:30:00+08:00,可读但低效 |
C#
2020-08-11
PHP 设计模式
2020-08-06
注:这是我在很久以前收藏的一篇文章,来自 IBM Developer,整理资料的时候被翻出来,贴出来算了。
设计模式只是为 Java™ 架构师准备的 —— 至少您可能一直这样认为。实际上,设计模式对于每个人都非常有用。如果这些工具不是 “架构太空人” 的专利,那么它们又是什么?为什么说它们在 PHP 应用程序中非常有用?本文解释了这些问题。
Email
2020-07-31
We can all agree that email communication is essential for successful businesses. However, for your emails to be successful and produce conversions, they have to land in the inbox.
我们都同意电子邮件通信对于成功的企业至关重要。但是,要使您的电子邮件成功并产生转化,它们必须进入收件箱。
But what happens when emails don’t make it to the inbox? Where do they go when they bounce? How are they processed?
但是,当电子邮件没有进入收件箱时会发生什么?当它们反弹时,它们会去哪里?它们是如何处理的?
Enter return-path.
使用 Return-Path 。
Return-path is a hidden email header that indicates where and how bounced emails will be processed. This header, also referred to as a bounce address or reverse path, is an SMTP address that is separate from your original sending address, and is used specifically for collecting and processing bounced messages.
Return-Path 是一个隐藏的电子邮件标头,指示处理退回电子邮件的位置和方式。此标头(也称为退回地址或反向路径)是独立于原始发送地址的 SMTP 地址,专门用于收集和处理退回的邮件。
Having a clear return-path system in place is incredibly important for your email program. It acts as a safeguard, protecting senders by providing a separate location for processing bounced emails. Your original sending inbox isn’t crowded by those “failed delivery” emails and that bounced messages are kept organized and together. Having a clear, organized return-path for bounced messages can also help your email deliverability and maintain your sending reputation.
拥有清晰的 Return-Path 系统对于您的电子邮件程序非常重要。它作为一种保护措施,通过提供单独的位置来处理退回的电子邮件来保护发件人。您的原始发送收件箱不会被那些“传递失败”的电子邮件所拥挤,并且退回的邮件保持井井有条并在一起。为退回的邮件提供清晰、有组织的 Return-Path 还有助于您的电子邮件送达率并保持您的发送声誉。
Why is return-path important?(为什么 Return-Path 很重要?)
Return-path is an important tool to have at your disposal, especially for mass email sends. Let’s say you’re sending an email blast about an offer your company is promoting to your entire email list. While we don’t want to see bounced emails, the reality is that messages can and do bounce for a variety of reasons.
Return-Path 是您可以使用的重要工具,尤其是对于群发电子邮件。假设您正在向整个电子邮件列表发送一封关于您的公司正在推广的优惠的电子邮件爆炸。虽然我们不希望看到退回的电子邮件,但现实情况是,由于各种原因,邮件可以并且确实会退回。
When you’re sending to large groups, you can get tens, maybe even hundreds of bounced messages depending on the size and nature of your campaign. These “failed delivery” messages then come back to haunt and crowd your original sending inbox. Instead, by having an established return-path, those messages are processed and stored separately in their own specified inbox.
当您向大型群组发送邮件时,您可能会收到数十甚至数百封退回的邮件,具体取决于广告系列的规模和性质。然后,这些“传递失败”消息会再次困扰并挤占您原来的发送收件箱。相反,通过建立 Return-Path ,这些邮件将单独处理并存储在其自己指定的收件箱中。
Return-path also helps with your deliverability and sending reputation by helping to validate your identity as a sender (i.e. whether or not you’re sending spam). Because return-path is a SMTP address, it can be used by servers and inbox providers to decide how or if they want to filter your messages. Having a properly set-up return-path can help provide credibility for your messages and subsequently you, the sender, which in turn boosts your sending reputation.
Return-Path 还有助于验证您作为发件人的身份(即您是否发送垃圾邮件),从而帮助您提高送达率和发送信誉。由于 Return-Path 是 SMTP 地址,因此服务器和收件箱提供商可以使用它来决定如何或是否要过滤您的邮件。正确设置 Return-Path 有助于为您的消息提供可信度,进而为您(发件人)提供可信度,从而提高您的发送声誉。
How return-path works(Return-Path 的工作原理)
Return-path works by directing where bounced messages should go when they cannot be delivered. It is usually set up by a developer or email platform provider, but can be customized using the Domain Authentication doc in our Knowledge Center.
Return-Path 的工作原理是指示退回的邮件在无法传递时应去哪里。它通常由开发人员或电子邮件平台提供商设置,但可以使用 我们知识中心的域身份验证文档进行自定义。
When a server or inbox provider receives your message, they validate your identity as a sender as well as your sending reputation before pushing you through to your intended recipients’ inboxes.
当服务器或收件箱提供商收到您的邮件时,他们会验证您作为发件人的身份以及您的发送信誉,然后再将您推送到目标收件人的收件箱。
In this validation process, DMARC and return-path work together to get you through these filters. DMARC examines your message to confirm that the domain provided in the “sent from” field matches the domain provided in the return-path field, which helps to validate your identity as a sender. Once these domains have been confirmed and matched by DMARC, you’ll have an easier time getting through filters set by servers and inbox providers.
在此验证过程中,DMARC 和 Return-Path 协同工作,帮助您通过这些过滤器。DMARC 会检查您的邮件,以确认“发件人”字段中提供的域与 Return-Path 字段中提供的域匹配,这有助于验证您作为发件人的身份。一旦 DMARC 确认并匹配了这些域名,您就可以更轻松地通过服务器和收件箱提供商设置的过滤器。
There are two types of bounced emails: hard bounces and soft bounces. Hard bounces occur when there are permanent issues with a recipient, including an invalid email address or typo in your mailing list. Soft bounces are more temporary and usually occur when there’s a problem with a recipient’s inbox, including file size or attachments issues or the possibility of a recipient having a full inbox.
退回电子邮件有两种类型:硬退回邮件和软退回邮件。当收件人存在永久性问题(包括邮件列表中的电子邮件地址无效或拼写错误)时,就会发生硬退回。软退回邮件是临时性的,通常在收件人的收件箱出现问题时发生,包括文件大小或附件问题,或者收件人的收件箱可能已满。
When a message hard bounces, the general best practice is to check that there are no typos in the recipient’s address. If there are none, you should remove the address from your mailing list. Keeping email addresses that hard bounce can damage your reputation as a sender and affect your deliverability in the long run.
当邮件被硬退回时,一般的最佳做法是检查收件人的地址中是否有拼写错误。如果没有,您应该从邮件列表中删除该地址。保留硬退回的电子邮件地址可能会损害您作为发件人的声誉,并从长远来看影响您的送达率。
When an email soft bounces, you have a little bit more wiggle room than with a hard bounce. Email addresses that soft bounce can be kept in your mailing list for future campaigns, but you’ll want to watch them to see if they bounce again. If they continue to bounce, they should be removed from your mailing list.
当电子邮件软退回时,与硬退回相比,您有更多的回旋余地。软退回的电子邮件地址可以保留在您的邮件列表中,以备将来的广告系列使用,但您需要观察它们,看看它们是否会再次退回。如果它们继续反弹,则应将其从您的邮件列表中删除。
个人 影视
2020-07-29

Linux Shell
2020-07-22
即便上了 ELK,也不可能所有日志往里面塞,搜日志是程序员的日常工作之一。
以 grep log by time efficiently 为关键词搜到 SO 上的这个问题: What is the most efficient way to extract logs between two time stamps?
要求:
- 能够过滤出指定时间段日志
- 效率,保证即便是大日志也不至于等太久,减少对服务的不良影响
提问的人自己提出来的方案:
grep -a -A 1000000 "03/09" fileName.txt | grep -a -B 1000000 "03/10"
他认为不好,因为有点慢,而且有时会漏掉一些日志。
漏掉日志可能和他的日志格式有关,这倒应该问题不大,主要是这个方案看起来就确实效率不行。
PS:如果不用模式匹配,可以加上 -F,应该可以提高效率。
# 2020/07/22 10:00:00,100 INFO [main] com.example.LoggingApplication - Starting Application
awk '$2>="16:30:00"{s=1} s; $2>="17:00:00"{exit}' event.log
这个看起来很牛逼,主要是有一个 exit。
Linux Shell
2020-07-21
这篇文章不是要记录那些乱七八糟的转义规则,而是讲怎么借助工具避开它。
GitHub 上偶然看到一个仓库 chrissimpkins/shellescape,做了些实验之后,发现非常好用。
别看就几行代码,真的感觉世界都清静了。
PS:代码我没细看,人生短暂,我不想去记这些没用的知识点。
import re
_find_unsafe = re.compile(r'[^\w@%+=:,./-]').search
def quote(s):
if not s:
return "''"
if _find_unsafe(s) is None:
return s
return "'" + s.replace("'", "'\"'\"'") + "'"
示例:
commands = """
grep -F '"userId": "1"' /tmp/test.log
grep 'aaa.bbb.$100.*' /tmp/test.log
""".strip().splitlines()
for command in commands:
print(quote(command))
Linux Shell
2020-07-20
快速输入上一行命令的最后一个参数
touch nihao.txt
code !$
创建目录并进入
take xxx # oh-my-zsh
mkdir xxx && cd $_
重命名
for i in {0..100}; do touch aaa_bbb_$i.jpg; done
rename 's/_bbb//' aaa_*.jpg
# for zsh
autoload zmv
zmv -n '(*)_(*).jpg' '$2_$1.jpg'
个人
2020-07-19

除了开发文档,我好像很少花时间看书。看书的时候也就是挑选一点内容浏览一下,就像查字典一样。可能这就叫碎片化阅读的时代。
我现在的阅读都转到的网上,内容一般都是来自:
- 阮一峰的博客(主要是科技爱好者周刊,每周五更新,必看)
- 开源中国 (动弹功能和周一乱弹被关闭真是一个很大的遗憾)
- 开发者头条 (toutiao.io)
- 知乎,刷知乎已经成瘾了
- 微信公众号
- 高性能服务器开发
- 架构师之路
- 开发内功修炼
- ...
- 抖音
- 澎湃新闻
- 博客园(已经去的少了,偶尔去看看列表页面有没有感兴趣的内容)
- GitHub(看代码也算吧,还有搜索一些关键词,了解一下热门项目)
- StackOverflow 没有它我就不会编程 😵
2021 年的变化:
- 开源中国的动弹功能(大概就类似发推,之前还是很热闹的)已经被阉割掉了,甚至很长时间评论功能都关闭了。
现在也去的少了。
- 博客园也由于整改,好多页面都不能访问,还在逐渐解封中。
2021/07/23:
- GitHub Copilots 也开始变成我工作的好搭档了,不管是写文档,还是写代码,我觉得它的输出也可以当做一个阅读源。
虽然它现在可能看起来还有点呆,写代码也没见提出很好的建议,但是和它一起工作还是很开心。
尤其是感觉我在训练它写作或者编程,让它成为更好的自己,心里有一丝丝成就感油然而生。
Git
2020-07-16
创建分支:
git branch <new-branch-name> <commit-id>
git checkout -b <new-branch-name> <commit-id>
删除远程分支:
git push --delete origin dev0404
删除远程已经不存在的分支:
git remote prune origin -n
git remote prune origin
已经合并到指定分支的分支:
git branch --merged master
# -r, --remote
git branch -r --merged master
创建独立分支(空白分支):
git checkout --orphan newbr
合并无关分支:
git merge newbr --allow-unrelated-histories