寻求一个好的方案

357 天前
 jwh199588
现在有两张表
```mysql
表 1: 用户表 2W 条数据
手机号
姓名

表 2: 休假表 10W 数据(一直增长中)
申请人(手机号)
交接人(手机号)
```
现在呢,导出休假表全量数据的时候,需要获取到申请人和交接人的姓名,导出格式如下
`申请人 申请人姓名 交接人 交接人姓名`

目前我想到两种方案:
第一种:每获取休假表 1000 条数据,然后去用户表获取对应手机号的的姓名
第二种:使用 mysql ,用休假表的申请人关联用户表,在用休假表的交接人关联用户表,意思就是连续关联两次休假表

但是我觉得这两种方案都不怎么好,请问大家还有其他好的方案吗
1803 次点击
所在节点    程序员
14 条回复
renmu
357 天前
就这点数据直接都拿出来放到内存处理应该也没啥问题,全量导出也不是啥频繁操作的东西
iOCZ
357 天前
联表查询不是一般操作么?
aru
357 天前
直接 join 就行了,有性能问题再说
yinmin
356 天前
2 次 join 是正解。
taotaodaddy
356 天前
join
oneisall8955
356 天前
做好覆盖索引(手机号+姓名),不回表,这点数据量没问题
qIssac
356 天前
这数据量太小了,mysql 两次 join 一点问题没有
ql562482472
356 天前
内存处理 这点东西。。
xwayway
356 天前
这点数据量,直接 join 不会有任何问题……
xuanbg
356 天前
就这点数据还不直接 join 么?而且你这个 join 都不会产生笛卡尔积的,怕什么。
ashe900501
356 天前
把用户表全部读入到内存,然后轮询休假表?个人想法。
azui999
356 天前
就这点东西,量级再乘以 100,单机也足够操作
humbass
356 天前
又不是几个亿的数据,速度没要求直接 join ,有要求的话通过 redis 处理
jwh199588
356 天前
这个任务的数据量确实不大,我只是想通过这个做一个延伸,如果在后面遇到了大数据量,该如何处理

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/938043

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX