记录－交流－Web开发知识分享
一，先说一下为什么要分表
当一张的数据达到几百万时，你查询一次所花的时间会变多，如果有联合查询的话，我想有可能会死在那儿了。分表的目的就在于此，减小数据库的负担，缩短查询时间。
根据个人经验，mysql执行一个sql的过程如下：
1,接收到sql;2,把sql放到排队队列中 ;3,执行sql;4,返回执行结果。在这个执行过程中最花时间在什么地方呢？第一，是排队等待的时间，第二，sql的执行时间。其实这二个是一回事，等待的同时，肯定有sql在执行。所以我们要缩短sql的执行时间。…
在说明系统数据库之前，先来看下MySQL在数据字典方面的演变历史：
MySQL4.1 提供了information_schema 数据字典。从此可以很简单的用SQL语句来检索需要的系统元数据了。
MySQL5.5 提供了performance_schema 性能字典。 但是这个字典比较专业，一般人可能也就看看就不了了之了。
MySQL5.7 提供了 sys系统数据库。 sys数据库里面包含了一系列的存储过程、自定义函数以及视图来帮助我们快速的了解系统的元数据信息。
sys系统数据库结合了information_schema和performance_schema的相关数据，让我们更加容易的检索元数据。 现在呢，我就示范下几种场景下如何快速的使用。…
MySQL主从复制环境中，如何才能保证主从数据的一致性呢？
现在常用的MySQL高可用方案，十有八九是基于 MySQL的主从复制（replication）来设计的，包括常规的一主一从、双主模式，或者半同步复制（semi-sync replication）。
我们常常把MySQL replication说成是MySQL同步（sync），但事实上这个过程是异步（async）的。大概过程是这样的：…
写这篇文章之前已经看过了很多数据库方面的优化内容，大部分都是加索引、使用事务、要什么select什么等等。然而，只是停留在阅读的层面上，很少有实践，因为没有遇到真实的项目，一切都是纸上谈兵。实践是检验真理的唯一标准，于是就想在数据库上测试一些性能优化的方案，比如索引之类的，但是不想使用假的数据，于是就想着能不能抓取网上的一些数据来作分析，后来自己通过PHP抓取了一些数据(爬取数据博文)，抓了大约110W的用户数据之后，当然需要统计一下具体的数量，于是我使用了以下的SQL语句（我使用的存储引擎是InnoDB）：
SELECT COUNT(*) FROM zh_user;Inside君整理了一份最新基于MySQL 5.6和5.7的配置文件模板，基本上可以说覆盖90%的调优选项，用户只需根据自己的服务器配置稍作修改即可，如InnoDB缓冲池的大小、IO能力（innodb_buffer_pool_size，innodb_io_capacity)。特别注意，这份配置文件不用修改，可以直接运行在MySQL 5.6和5.7的版本下，这里使用了小小的技巧，具体可看配置文件。如果配置参数存在问题，也可以及时反馈Inside君，我们一起成长。
触发Inside君做这件事情的原因是大部分网络上的MySQL配置文件都非常非常古老，大多都是基于MySQL 5.1的版本，这导致了绝大部分MySQL并没有运行在最优的环境，从而导致一些错误的使用，亦或是灾难性事故的发生，比如数据丢失，主从数据不一致等。而这些问题早在5.6版本及以后的版本中得到了解决。…
数据库范式在数据库设计中的地位一直很暧昧，教科书中对于数据库范式倒是都给出了学术性的定义，但实际应用中范式的应用却不甚乐观，这篇文章会用简单的语言和一个简单的数据库DEMO将一个不符合范式的数据库一步步从第一范式实现到第四范式。
应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：
1.减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）
2.消除异常（插入异常，更新异常，删除异常）
3.让数据组织的更加和谐……
关于秒杀
随着双11活动的不断发展，小米饥饿营销模式的兴起，“秒杀”已经成为一个热点词汇。在一些活动中，热销商品会以惊人的速度售罄，比如最近Inside君在抢购美图M4手机，12点开卖，1分钟之内就被售罄。
对 于关注数据库的Inside君来说，更关心的是如何高效的实现秒杀应用。之前淘宝在2013年的数据库大会上分享过他们的秒杀方案，修改MySQL数据库 源码来实现高效的秒杀应用。但是，那篇分享过于高大上，没有给出具体的实现过程。另外，从其他渠道打听到的是这个方案并没有在生产环境上线，不知道有没有 其他知道内幕的小伙伴，具体来说说淘宝的方案是否有上线。…
INNODB存储引擎UTF85000W以内
近期评论