mysql如何设计个人名片系统_mysql图文混合存储方案

优先用传统字段而非JSON存名片数据：文字类字段拆列并建索引，图片存相对路径，动态字段用扩展表，搜索用前缀匹配+拼音字段，通知异步解耦，富文本须过滤XSS。用 TEXT 还是 JSON 字段存名片图文混合数据？MySQL 8.0+ 支持 JSON 类型，但个人名片系统里，别一上来就选 JSON。它查起来不走索引（除非建虚拟列+索引），更新单个字段还得全量写入，反而拖慢高频读写的名片详情页。真正适合的场景是：字段结构稳定、查询条件明确（比如按公司名查、按职位模糊搜）——这时候用传统字段更直接。常见错误现象：JSON 存了 {"name":"张三","avatar":"/imgs/a1.jpg"}，结果想按 avatar 路径做 CDN 预加载，却发现没法在 WHERE 里高效过滤；或者前端传回修改后的整个 JSON，后端没做 diff 就 UPDATE，白白触发 binlog 和从库同步。头像、二维码等二进制内容，一律存路径（VARCHAR(255)），文件本身走对象存储（OSS/S3）文字类字段（姓名、电话、职位、公司、简介）拆成独立列，加好 INDEX（比如 INDEX idx_company (company)）如果真有动态扩展字段（如“微信 ID”“钉钉号”“小红书主页”），用单独的 profile_ext 表 + key/value 结构，别塞 JSON图片路径怎么存才不怕迁移和 CDN 切换？硬编码域名或协议（"https://cdn.example.com/xxx.jpg"）是典型坑。一旦换 CDN 域名或上 HTTPS 强制跳转，所有老数据就裂开；本地开发环境还可能直接 404。正确做法是只存相对路径或资源标识符，由应用层拼接前缀。数据库里字段定义为 avatar_path VARCHAR(255)，值为 "u/123/avatar_v2.jpg" 这类无协议、无域名的路径。避免存完整 URL，包括 http:// 或 // 开头的协议相对 URL路径中别含用户 ID 明文（如 "uid_789/avatar.jpg"），防止被枚举；可用短哈希或服务端映射如果支持多图（如名片背面扫描件），用关联表 card_images，而不是在主表加多个 img1/img2 字段如何让搜索姓名/公司时支持中文分词和模糊匹配？MySQL 默认的 LIKE '%关键词%' 在大数据量下会全表扫，而且不支持“张三丰”匹配“张三”。InnoDB 的全文索引（FULLTEXT）对中文基本无效——它按空格切词，而中文没空格。 There’s An AI For That 全球领先的 AI 聚合器，收集10,225个AI工具，可用于超过2,548个任务。