方案A：两张表格,A表格约1W条，秒级更新；B表格(很少查询)为A表的复制，每间隔1小时完全复制一次，那么一年下来有8760W条。
方案B：A表格约1W条，秒级更新；1万张B表格，为A表格没一条的复制每间隔1小时复制一次。
现在选用My Sql数据库，请问是否合理（数据库选型，表格规划），后期如何优化，及1台服务器能撑多久。请求高手给个建议，或说说你的观点。
感觉都不怎么合理，你的目的无非是想把大批量的数据分开存储，不至于给某个表产生巨大压力。但是这个间隔1小时这一步就会出问题，你怎么控制读取多少条，因为他不见得就是1万条，下次再读会不会有重复的，或者丢失的。
你读了1万条，然后又瞬间批量插入另一个表，万一这一步卡住了怎么办，同时插一万条也是瞬间对数据库的cpu产生巨大压力，如果和业务库的数据库用同一台主机，那么业务库可能直接就不工作了。
再说你也保证不了读取了脏数据，还不说你读的过程中某条数据正在被修改，产生了数据锁。
这其实不是1万个表和单表的问题，而是方案就不靠谱。
使用数据库自带的触发器来控制条数或者时间存储，另外第二个方案比第一个要好一些吧，
建议第二个方案的表的存储数量增多一些，一万记录的表记录的操作还是挺快的。
第二个方案的表名问题可以时间命名。
供参考。
感觉直接用sharding jdbc做分库分表就行了，1万台机器并不多，可以自己定个规则 按年或者什么的分库，按规则分个几百张表就可以了。所谓的备份那些都是没用的，不属于这个系统
可以用macat数据库中间件来做分片和读写分离,主节点增删操作 从节点查询操作 让从节点监控主节点的二进制日志进行主从复制