怎么实现redis的数据库的缓存
大致为两种措施：
一、脚本同步：1、自己写脚本将数据库数据写入到redis/memcached。2、这就涉及到实时数据变更的问题（mysql row binlog的实时分析），binlog增量订阅Alibaba 的canal ，以及缓存层数据 丢失/失效 后的数据同步恢复问题。
二、业务层实现：1、先读取nosql缓存层，没有数据再读取mysql层，并写入数据到nosql。2、nosql层做好多节点分布式（一致性hash），以及节点失效后替代方案（多层hash寻找相邻替代节点），和数据震荡恢复了。
redis实现数据库缓存的分析：
对于变化频率非常快的数据来说，如果还选择传统的静态缓存方式（Memocached、File System等）展示数据，可能在缓存的存取上会有很大的开销，并不能很好的满足需要，而Redis这样基于内存的NoSQL数据库，就非常适合担任实时数据的容器。
但是往往又有数据可靠性的需求，采用MySQL作为数据存储，不会因为内存问题而引起数据丢失，同时也可以利用关系数据库的特性实现很多功能。所以就会很自然的想到是否可以采用MySQL作为数据存储引擎，Redis则作为Cache。
MySQL到Redis数据复制方案，无论MySQL还是Redis，自身都带有数据同步的机制，比较常用的MySQL的Master/Slave模式，就是由Slave端分析Master的binlog来实现的，这样的数据复制其实还是一个异步过程，只不过当服务器都在同一内网时，异步的延迟几乎可以忽略。那么理论上也可用同样方式，分析MySQL的binlog文件并将数据插入Redis。
因此这里选择了一种开发成本更加低廉的方式，借用已经比较成熟的MySQL UDF，将MySQL数据首先放入Gearman中，然后通过一个自己编写的PHP Gearman Worker，将数据同步到Redis。比分析binlog的方式增加了不少流程，但是实现成本更低，更容易操作。
mysql单表存储数据量有上限吗
单张表多少个字段其实没有什么定论，只要不超过数据库限定的个数就好，但是表的单条记录的大小是有合理空间的，也就是需要根据具体硬件和操作系统来确定单条记录（row size）的大小：
一般来说，现在硬盘的扇区大小都是4K（有些硬盘可以到16K），所以存储基于操作系统的MySQL单条记录的合理大小应不超过硬盘的扇区大小。如果超出意味着查找单条记录时需要多个磁盘扇区去查找，增加了寻道时间，单表数据量大了性能会下降。同时MySQL配置的缓存页大小即innodb_page_size，也要配置成硬盘扇区大小差不多大小，从而减少数据库checkpoint从缓存往磁盘写数据的工作量。
话说回来，其实这些并不十分重要，因为一般系统出现性能问题大概率是在应用程序的质量上。
在mysql中，每个数据库最多可创建20亿个表，一个表允许定义1024列，每行的最大长度为8092字节（不包括文本和图像类型的长度）。当表中定义有varchar、nvarchar或varbinary类型列时，如果向表中插入的数据行超过8092字节时将导致Transact-SQL语句失败，并产生错误信息。SQLServer对每个表中行的数量没有直接限制，但它受数据库存储空间的限制。每个数据库的最大空间1048516TB，所以一个表可用的最大空间为1048516TB减去数据库类系统表和其它数据库对象所占用的空间。