用mysql的复制和读写分离解决了读压力的问题，那写压力能否也通过复制来解决？答案是否定的： 利用缓存合并多次写入为一次，例如：浏览数量可以写入redis，达到n条再一次写入mysql拆分数据库到不用的服务器集群：合理设计好库和表，避免跨库查询后进行拆分操作：按需求建立新的db集群同步拆分的db到新的集群中迁移数据库账号到对应的新集群修改应用的数据连接删除链
安装：.100服务器建立mysql账号并授权： 建立路由模块账号（需要读取mysql权限信息的）： .102服务器： 加密密码配置到配置文件： （根据真实cpu核数来） （配置具体服务器） （监控模块配置） （读写模块配置）启动maxscale：ps -
（先对数据库操作进行读写分离，使得具有master角色的主服务器主要用于执行写操作，这样就能大大减少主服务器由于读操作而产生的负载过大的问题。读交给slave。对于多台读服务器，还要把读操作的压力分摊到不同的slave服务器上。通常来说，读写分离和多台slave服务器的读负载均衡也是两个不同的问题，也要分别进行解决。先读写分离，再将读操作平均分摊到各slave服务器）redis和memcache差
主从数据库服务器的数据会最终一致（因为mysql复制是异步的，总会存在延迟），看似解决了单点问题，然而该方案并不完美。因为一旦主服务器宕机，必须手动把读写连接切换到原来的从服务器上，而这个过程需要时间，短则几分钟，长则数小时，这期间服务会出于瘫痪状态。怎样在master宕机后，自动切换数据库连接呢？ 最简单的是使用虚拟ip：
除了基于日志点的复制，mysql5.6版本之后还有基于GTID的复制方式：GTID也就是全局事务idGTID能保障每个在主上提交的事务在复制集群中可以生成一个唯一的id值需要在主从数据库配置文件中同时加入如下配置： gtid_mode：开启 enforce-gtid-consistency：强制gtid一致性（用于保障gt
一些mysql版本并不会开启二进制日志，所以一定要检查是否开启。如果一开始没开启，在以后需要开启，则必须重启数据库服务器，而数据库服务器重启会对业务造成很大影响。所以，尽管二进制日志会对性能有稍许影响，所以，无论是否要用复制、备份功能(增量日志也依赖二进制日志)，都建议开启 目前mysql支持两种复制类型： 1.二进制日志点
数据库的主从复制并不能取代备份（如被误删的数据）（memory引擎只能备份结构）（增量备份只能通过mysql的二进制日志来实现）mysqldump常用参数：在进行mysql备份时，要给一个用户以权限(包括操作数据的相关命令的权限)：mysqldump示例：（创建帐号，并授权相应操作权限）......未完待续......
慢查询记录：可能会产生很多慢查询日志，人工这样查看慢查询日志很费时间，可以用mysql提供的工具mysqldumpslow：（只是多出了count，该sql语句执行的次数。也就是慢查询日志中多次出现该查询语句，只显示一次）
possible_keys、key、key_len都为null，可见在表上是没有可用索引的计算区分度，越接近1区分度越好，应该放到联合索引的左侧建好联合索引之后的explain：翻页越多，速度越慢，进一步优化：优化的前提：comment_id是商品评论表的主键，且有覆盖索引原理： 利用覆盖索引，取出主键comment_id，再进行排序，取出所需数据，之后再同评论表通过主键来排序，取出
告诉我们mysql优化器是怎样处理我们的sql请求的并不是说在相关查询列上有索引，mysql在查询时就能使用到，虽然我们认为适合，但mysql优化器不一定这样认为mysql并不一定根据我们sql语句中的顺序进行表的关联，而是根据据索引的统计信息，自动调整关联顺序（id只能是两种值：数字，null。数字表示sql对数据库的select操作顺序/数量；如果是null则表示几个语句union产生的结果集
商品模块：（虽然要尽量做到冷热数据分离，减小表的宽度。但商品信息表中的字段差不多要在一起使用的；另一方面，对于经常使用的商品详细信息，一般会放到缓存中，或者做页面静态化加快访问速度。基于这两点，没有对商品信息表做拆分）订单模块：
哈希分区：（如果是非整型的列，可以用函数把它转为整型）（非整型转为整型的函数）往分区后的表中插入、查询数据是用一样的语句：range分区：（上图中，如果不建立p3分区，则大于30000的数据插入会报错）list分区：实战，为用户登录日志表分区：可以这样分区：（当然，转换为时间的逻辑可以放到应用层，以节省数据库性能）增加分区的方法很简单：alter table customer_login_log
（建立一个和原表相同的新表，并做表结构修改，然后将原表中的数据复制到新表中，并在原表上增加触发器，把表新增的数据也复制到新表中，在行的所有数据完成后，在原表上增加个时间很短的时间锁，把新表命名成原表，再删除原来的表）
（预编译的好处：1.可以重复使用执行计划，减少sql编译所需时间。2.一次解析多次使用。3.避免sql注入。）（列和参数类型不一致时，会造成隐式转换） not in可能造成索引失效 比如：sql注入了一个数据库，但无法看到另一个数据库 （子查询的结果会存到临时表中，无论内存临时表还是磁盘临时表，都无法使用索引） 而or很少能用到索引
decimal比用varchar保存bigint无法保存的数据更加高效
（索引可以增加查询效率，但同样会降低插入和更新的效率）（所以要求每个innodb表必须有一个主键） 因为innodb是索引组织表的缘故，如果主键频繁被更新，意味着数据存储的逻辑数据要频繁变动，必然带来大量io操作和cpu时间，降低性能，特别是对大表 uuid、md5、hash、字符串不是顺序增长的，数据插入的时候为保障索引的顺序，会进行排序插入，占用大量cpu时间，和i
（如果两个关联的列的数据类型不一样，在关联的时候会进行隐式转换，造成列上索引失效，查询效率大幅降低）没特殊需求的情况下，统一使用innodb统一字符集可以避免由于字符集转换产生的乱码，数据库和表字符集统一使用utf8（如果要存表情符号还要用utf8的扩展字符集，但一定要统一）所有表和字段都要加注释从一开始就进行数据字典的维护尽量控制单表数据量的大小（历史数据归档、分库分表），建议控制在500w行内
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
