河北网站备案多久wordpress gif 压缩

河北网站备案多久,wordpress gif 压缩,我要制作网站,怎样做视频播放网站前言大家好最近一位星球粉丝说#xff0c;他去面试了字节#xff0c;问了这么一道题#xff0c;20亿手机号存储#xff0c;选int还是string#xff1f;varchar还是char#xff1f;为什么#xff1f;他支支吾吾回答了几句#xff0c;好像看起来#xff0c;面试官面色凝…前言大家好最近一位星球粉丝说他去面试了字节问了这么一道题20亿手机号存储选int还是stringvarchar还是char为什么他支支吾吾回答了几句好像看起来面试官面色凝重对他不是很满意果然最好还是挂了。。。本文跟大家聊聊我的思路。20亿数据用Int存储存在哪些问题bigInt行不行面试官的隐藏考察点日常开发避坑点1. 20亿数据用Int或者Long存储存可能有在哪些问题1.1 int存得下11位数字嘛首先我们都知道手机号是11位的数字比如13728199213.在Java中int是 32位最大值为2^31 - 1 2,147,483,647。约等于 2×10⁹。显然如果用int根本存不下 11位的手机号码。要想存的下得用64位的Long类型也就是对应数据库的bigInt。1.2 数据完整性例如手机号01324567890用Long存会变成1324567890直接破坏数据完整性。ini体验AI代码助手代码解读复制代码Long phoneNumber 01324567890L; //编译报错Java不允许前导0的Long整数并且有时候有些手机号可能包含国家代码如86或者有些时候是有连字符的比如137-2819-9213. 这些原因都导致不能用整型类型存储。1.3 查询麻烦比如你要查找手机号是137开头的手机号号码如果用BigInt(Long类型)需先转字符串再模糊匹配效率暴跌。2. 用String有哪些好处保真数字、符号、前导零全能存原样保留。灵活支持模糊查询、国际号码扩展无忧。省心无需担心溢出或格式转换问题。sql体验AI代码助手代码解读复制代码CREATE TABLE user_tab ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 用户ID, phone_number VARCHAR(20) NOT NULL COMMENT 手机号, PRIMARY KEY (id), UNIQUE KEY idx_phone (phone_number) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT用户表;2. 面试官的隐藏考察点面试的时候面试官主要考察候选人的一些业务扩展性、数据容错性、思考问题全面性等能力。我们先通过为什么用 VARCHAR(20) 而不是 VARCHAR(11)来给面试官秀一波肌肉~~2.1 为什么用 VARCHAR(20) 而不是 VARCHAR(11)我们就拿手机号来说为什么更建议用 VARCHAR(20)而不是VARCHAR(11)呢因为我们都知道手机号是11位的为什么不直接用VARCHAR(11)呢如果你日常开发中就有思考数据容错性习惯的话就会想到如果遇到国际号码861382222333314位带国家码的号码00861382222333315位分机号13822223333#123超11位这些场景都会导致VARCHAR(11)报错崩盘。其次就是业务扩展性思考VARCHAR(11)只能存纯11位数字假设未来业务需要支持座机号如010-62223333含横杠支持虚拟号如17012341234-5678支持其他登录方式如邮箱手机号混合存储因此字段长度和类型需提前为业务变化留余地避免频繁改表。这就是日常开发中的业务扩展性思维思考。还有数据容错性思考输入不可控性用户可能输入带空格/符号的号码如138 2222 3333直接存原始值更方便清洗。设计妥协若强制用VARCHAR(11)需在代码层严格过滤非数字字符增加复杂度。还有思考问题全面性比如存储成本思考。VARCHAR(11)最大占 11字节utf8mb4下1字符占4字节但数字和号只占1字节VARCHAR(20)最大占 20字节20亿数据相差仅约 18GB和用BIGINT的16GB对比总成本仍可接受。所以面试官期待的答案公式体验AI代码助手代码解读复制代码合理长度 基础需求 国际扩展 容错缓冲当然这个不是固定答案主要还是面试的时候你回答面试官的思路和表达最好体现你有这几个方面的思考业务扩展性、数据容错性、思考问题全面性。2.2 极端场景如果手机号是纯数字并且第一位不是0的话可以用BIGINT的但是永远不要使用INT。通过这些极端场景的举例也体现你思考问题全面性的一个能力。3. 日常开发避坑点设计手机号存储的时候有哪些需要避的坑的。主要有这几个吧3.1 字段长度设计过小用 VARCHAR(11) 只存纯数字遇到 861382222333314位直接截断。用 VARCHAR(20) 兼容国际号、分机号如 13822223333#123。3.2 字符集和排序规则使用 utf8 字符集无法存储 emoji 或特殊符号用 utf8mb4 utf8mb4_unicode_ci兼容所有 Unicode 字符如 * #。3.3 索引设计不当未对手机号加唯一索引导致重复数据。sql体验AI代码助手代码解读复制代码添加 UNIQUE 约束ALTER TABLE user ADD UNIQUE INDEX idx_phone (phone);3.4 数据清洗与校验缺失用户输入 138-2222-3333 或 138 222 23333直接存储导致格式混乱。入库前统一清洗移除空格、横杠等符号只保留 和数字。正则校验例如 ^?\d{8,20}$允许带 号的 8~20 位数字。3.5 忽视隐私与安全明文存储手机号泄露用户隐私。加密存储使用 AES 加密或数据库内置加密函数。脱敏显示查询结果返回 138****3333。3.5 风控校验css体验AI代码助手代码解读复制代码// 严格校验11位纯数字无国际码 String regex ^1(3[0-9]|4[579]|5[0-35-9]|6[2567]|7[0-8]|8[0-9]|9[0-35-9])\\d{8}$; // 宽松校验允许带国际码如86 13812345678 String looseRegex ^(\\\\d{1,3})?1(3\\d|4[579]|5[0-35-9]|6[2567]|7[0-8]|8\\d|9[0-35-9])\\d{8}$;