[高并发问题] MySQL 分区的情况下不能使用自增 ID，若使用 UUID 与时间做联合主键，数据量特大时，查询库效率如何？

用户余额放 redis 不妥，按你们这个数据量读写缓存频率很高，redis 又是单进程的容易成为瓶颈。

使用 update money = money - cost where uid = xx and money >= cost 这条 sql 可以保证不出现余额为负的情况，并且通过 affected rows 来判断是否扣款成功，这样就免去查余额的步骤了。

最终解决方式，将snowflake生成的ID存到了2个字段中，我将原来的snowflake生成ID改由32位改了26位，其中前13位是时间戳微秒，后13位是机器码线程码和序列码，刚好分成2个bigint类型的字段。同时，我使用前13位的时间戳数字进行分区，最终效果还是非常不错的

@leo 我是把整个User对象序列化后放到了缓存，因为用户登录的频率也会很高，而且用户获取结果的频率会非常之高（一个上传请求对应50个查询请求，如果直接查库，肯定不行），若redis有这个瓶颈限制，是否还有其它好的解决方案。
我当前在测试中还遇到一个问题，也没找到原因：

环境：本地开发机器用的是DOCKER容器（nginx mariadb php7 redis） + lumen框架 + targetliu/phpredis包
表现：采用laravel开发的管理端页面没有缓存，直接查库的，访问日志表（每页15条数据展示），3条SQL语句直接查库
，再加上页面加载，总耗时18ms左右（比较稳定）
select * from `admins` where `id` = '1' limit 1
select count(*) as aggregate from `files`
select * from `files` order by `created_at` desc limit 15 offset 0

而加了redis的lumen，向result api获取结果时，只有缓存中没数据时，我才会从库中加载到缓存。
通常耗费时间是 8ms左右，但偶尔会有200ms以上 （5%概率）

上传文件api，我测试时采用的是不到100个字节的base64文件
上传api需要经过如下步骤：
验证 app key (缓存)  -> 验证文件 -> 验证类型ID（缓存）-> 验证用户及余额（缓存）->保存文件（Storage）->扣费  

表现比较奇怪：总耗时60ms左右（70%概率），耗时200～300ms（25%）,耗时300ms~1s(5%)

以上测试只是采用手工刷新页面

若用ab测试，并发100个连接，100000次请求，再手工请求的时候，耗时都是在700ms~1s~3s左右了
初步感觉可能是docker的瓶颈，还没有重新架环境测试

一个比较有意思的现象是用AB压测的时候，CPU占用还非常高....

最后xhprof工具可以检查到各种性能瓶颈的地方。目前的结论是不能使用UUID来做主键，会非常慢。
目前我尝试过使用twitter的https://github.com/Sxdd/php_snowflake/来生成唯一ID，但这玩意生成的数字太长，
保存到数据库里没问题，但显示到页面就被LARAVEL转成int类型越界了

mysql自带有uuid_sort()函数可以生成唯一ID，但通过DB::table()->create 或Model::create() 均无法得到这个ID
所以也比较郁闷，相当于我插入了一条数据，但我并不知道它的ID，这是我的业务逻辑所不允许的。如果有人知道在插入数据的同时获取到由MYSQL生成的非自增ID的话，请告诉我，谢谢。

最后通过近几天的测试，如果实在不行，只有考虑放弃使用MYSQL分区表的方式了，计划用脚本每天建立新表，然后 将旧数据移到新表中来并删除旧数据库中的数据，采用MYSQL的自增ID来做

@leo 使用laravel Eloquent Model 去$num = $model->update(['money' => 1]) 这个$num并不是affected rows, 你知道Eloquent的update如何获取到affected rows吗

@LinGod Model::getQuery()->where('id', $id)->update(['money' => 1])，这里的getQuery是获取 database 的 query builder，database query builder 的 update 方法返回的就是 affected rows

@leo 感谢, 困扰了挺久, 刚用laravel不久, $model->update(['money' => 1])一直返回的是true or false, 百度也没有相关方法

膜拜大神ing

这么大的表为什么不考虑分表和引入数据库中间件呢

@zhengzean 因为当前实际业务量并没有这么大，只是按这个规格来进行前期设计。不借助中间件的分表与分区在底层性能上一样的，但分表会让代码层面更加复杂，倒不如使用MYSQL自身的分区了，而借助中间件的的分布式架构分表，目前用不到。热数据只有10多分钟，之后就是冷数据，在业务量起来后，考虑将它们放到缓存的