BINLOG就是一个记录SQL语句的过程，和普通的LOG一样。不过只是她是二进制存储，普通的是十进制存储罢了。 1、配置文件里要写的东西： [mysqld] log-bin=mysql-bin(名字可以改成自己的，如果不改名字的话，默认是以主机名字命名) 重新启动MSYQL服务。 二进制文件里面的东西显示的就是执行所有语句的详细记录，当然一些语句不被记录在内，要了解详细的，见手册页。 2、查看自己的BINLOG的名字是什么。 show binlog events; query result(1 records) Log_name Pos Event_type Server_id End_log_pos Info yueliangdao_binglog.000001 4 Format_desc 1 106 Server ver: 5.1.22-rc-community-log, Binlog ver: 4 3、我做了几次操作后，她就记录了下来。 又一次 show binlog events 的结果。 query result(4 records) Log_name Pos Event_type Server_id End_log_pos Info yueliangdao_binglog.000001 4 Format_desc 1 106 Server ver: 5.1.22-rc-community-log, Binlog ver: 4 yueliangdao_binglog.000001 106 Intvar 1 134 INSERT_ID=1 yueliangdao_binglog.000001 134 Query 1 254 use test; create table a1(id int not null auto_increment primary key, str varchar(1000)) engine=myisam yueliangdao_binglog.000001 254 Query 1 330 use […]
View Details当大家发现数据库查询性能很慢的时候，大家都会想到加索引来优化数据库查询性能， 但是面对一个复杂的SQL语句，找到一个优化的索引组合对人脑来讲，真的不是一件很简单的事。 好在SQLSERVER提供了两种“自动”功能，给你建议，该怎么调整索引 第一种是使用DMV 第二种是使用DTA (database engine tuning advisor) 数据库引擎优化顾问 这篇文章主要讲第一种 从SQL2005以后，在SQLSERVER对任何一句语句做编译的时候，都会去评估一下， 这句话是不是缺少什么索引的支持，如果他认为是，他还会预估，如果有这麽一个索引 他的性能能提高多少 SQLSERVER有几个动态管理视图 sys.dm_db_missing_index_details sys.dm_db_missing_index_groups sys.dm_db_missing_index_group_stats sys.dm_db_missing_index_columns(index_handle) sys.dm_db_missing_index_details 这个DMV记录了当前数据库下所有的missing index的信息,他针对的是SQLSERVER从启动以来所有运行的语句， 而不是针对某一个查询。DBA可以看看，哪些表格SQLSERVER对他是最有“意见”的 以下是这个DMV的各个字段的解释： 1、index_handle:标识特定的缺失索引。该标识符在服务器中是唯一的。index_handle 是此表的密钥 2、database_id :标识带有缺失索引的表所驻留的数据库 3、object_id :标识索引缺失的表 4、equality_columns:构成相等谓词的列的逗号分隔列表 即哪个字段缺失了索引会在这里列出来（简单来讲就是where 后面的筛选字段）， 谓词的形式如下：table.column =constant_value 5、inequality_columns :构成不等谓词的列的逗号分隔列表，例如以下形式的谓词：table.column > constant_value “=”之外的任何比较运算符都表示不相等。 6、included_columns:用于查询的涵盖列的逗号分隔列表（简单来讲就是 select 后面的字段）。 7、statement:索引缺失的表的名称 比如下面这个查询结果 那么应该创建这样的索引
|
1 |
1 CREATE INDEX idx_SalesOrderDetail_test_ProductID_IncludeIndex ON SalesOrderDetail_test(ProductID) INCLUDE(SalesOrderID) |
在ProductID上创建索引，SalesOrderID作为包含性列的索引 注意事项: 由 sys.dm_db_missing_index_details 返回的信息会在查询优化器优化查询时更新，因而不是持久化的。 缺失索引信息只保留到重新启动 SQL Server 前。如果数据库管理员要在服务器回收后保留缺失索引信息， 则应定期制作缺失索引信息的备份副本 sys.dm_db_missing_index_columns(index_handle) 返回与缺少索引（不包括空间索引）的数据库表列有关的信息，sys.dm_db_missing_index_columns 是一个动态管理函数 字段解释 index_handle：唯一地标识缺失索引的整数。 sys.dm_db_missing_index_groups 返回有关特定缺失索引组中包含的缺失索引（不包括空间索引）的信息 sys.dm_db_missing_index_group_stats 返回缺失索引组的摘要信息，不包括空间索引 这个视图说白了就是预估有这麽一个索引，他的性能能提高多少 有一个字段比较重要: avg_user_impact: 实现此缺失索引组后，用户查询可能获得的平均百分比收益。该值表示如果实现此缺失索引组，则查询成本将按此百分比平均下降。 就是说，增加了这个缺失索引，性能可以提高的百分比 下面是MSDN给出的示例，缺失索引组句柄为 2
|
1 2 3 4 5 6 7 8 9 10 |
1 --查询提供缺失索引的数据库、架构和表的名称。它还提供应该用于索引键的列的名称 2 USE [AdventureWorks] 3 GO 4 SELECT migs.group_handle, mid.* 5 FROM sys.dm_db_missing_index_group_stats AS migs 6 INNER JOIN sys.dm_db_missing_index_groups AS mig 7 ON (migs.group_handle = mig.index_group_handle) 8 INNER JOIN sys.dm_db_missing_index_details AS mid 9 ON (mig.index_handle = mid.index_handle) 10 WHERE migs.group_handle = 2 |
示例代码：
|
1 2 3 4 5 6 |
1 USE [AdventureWorks] --要查询索引缺失的数据库 2 GO 3 SELECT * FROM sys.[dm_db_missing_index_details] 4 SELECT * FROM sys.[dm_db_missing_index_groups] 5 SELECT * FROM sys.[dm_db_missing_index_group_stats] 6 SELECT * FROM sys.[dm_db_missing_index_columns](1) --1 ：1是根据dm_db_missing_index_details查出来的 |
[…]
View Details今天中午，有朋友叫我帮他看一下数据库，操作系统是Windows2008R2 ,数据库是SQL2008R2 64位 64G内存，16核CPU 硬件配置还是比较高的，他说服务器运行的是金蝶K3软件，数据库实例里有多个数据库 现象 他说是这几天才出现的，而且在每天的某一个时间段才会出现CPU占用高的情况 内存占用不太高，只占用了30个G CPU占用100% 排查方向 一般排查都是用下面的脚本，一般会用到三个视图sys.sysprocesses ,dm_exec_sessions ,dm_exec_requests
|
1 2 3 4 5 |
USE master GO --如果要指定数据库就把注释去掉 SELECT * FROM sys.[sysprocesses] WHERE [spid]>50 --AND DB_NAME([dbid])='gposdb' SELECT COUNT(*) FROM [sys].[dm_exec_sessions] WHERE [session_id]>50 |
看一下当前的数据库用户连接有多少 然后使用下面语句看一下各项指标是否正常，是否有阻塞，这个语句选取了前10个最耗CPU时间的会话
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
SELECT TOP 10 [session_id], [request_id], [start_time] AS '开始时间', [status] AS '状态', [command] AS '命令', dest.[text] AS 'sql语句', DB_NAME([database_id]) AS '数据库名', [blocking_session_id] AS '正在阻塞其他会话的会话ID', [wait_type] AS '等待资源类型', [wait_time] AS '等待时间', [wait_resource] AS '等待的资源', [reads] AS '物理读次数', [writes] AS '写次数', [logical_reads] AS '逻辑读次数', [row_count] AS '返回结果行数' FROM sys.[dm_exec_requests] AS der CROSS APPLY sys.[dm_exec_sql_text](der.[sql_handle]) AS dest WHERE [session_id]>50 AND DB_NAME(der.[database_id])='gposdb' ORDER BY [cpu_time] DESC |
如果想看具体的SQL语句可以执行下面的SQL语句，记得在SSMS里选择以文本格式显示结果
|
1 2 3 4 5 6 7 8 |
--在SSMS里选择以文本格式显示结果 SELECT TOP 10 dest.[text] AS 'sql语句' FROM sys.[dm_exec_requests] AS der CROSS APPLY sys.[dm_exec_sql_text](der.[sql_handle]) AS dest WHERE [session_id]>50 ORDER BY [cpu_time] DESC |
模拟了一些耗CPU时间的动作 还有查看CPU数和user scheduler数和最大工作线程数，检查worker是否用完也可以排查CPU占用情况
|
1 2 3 4 |
--查看CPU数和user scheduler数目 SELECT cpu_count,scheduler_count FROM sys.dm_os_sys_info --查看最大工作线程数 SELECT max_workers_count FROM sys.dm_os_sys_info |
查看机器上的所有schedulers包括user 和system 通过下面语句可以看到worker是否用完，当达到最大线程数的时候就要检查blocking了 对照下面这个表 各种CPU和SQLSERVER版本组合自动配置的最大工作线程数 CPU数 32位计算机 64位计算机 <=4 256 512 8 288 576 16 352 704 32 480 960
|
1 2 3 4 5 6 7 8 |
SELECT scheduler_address, scheduler_id, cpu_id, status, current_tasks_count, current_workers_count,active_workers_count FROM sys.dm_os_schedulers |
如果SQLSERVER存在要等待的资源，那么执行下面语句就会显示出会话中有多少个worker在等待 结合[sys].[dm_os_wait_stats]视图，如果当前SQLSERVER里面没有任何等待资源，那么下面的SQL语句不会显示任何结果
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
SELECT TOP 10 [session_id], [request_id], [start_time] AS '开始时间', [status] AS '状态', [command] AS '命令', dest.[text] AS 'sql语句', DB_NAME([database_id]) AS '数据库名', [blocking_session_id] AS '正在阻塞其他会话的会话ID', der.[wait_type] AS '等待资源类型', [wait_time] AS '等待时间', [wait_resource] AS '等待的资源', [dows].[waiting_tasks_count] AS '当前正在进行等待的任务数', [reads] AS '物理读次数', [writes] AS '写次数', [logical_reads] AS '逻辑读次数', [row_count] AS '返回结果行数' FROM sys.[dm_exec_requests] AS der INNER JOIN [sys].[dm_os_wait_stats] AS dows ON der.[wait_type]=[dows].[wait_type] CROSS APPLY sys.[dm_exec_sql_text](der.[sql_handle]) AS dest WHERE [session_id]>50 ORDER BY [cpu_time] DESC |
比如我当前执行了查询SalesOrderDetail_test表100次，由于表数据非常多，所以SSMS需要把SQLSERVER执行的结果慢慢的取走， 造成了ASYNC_NETWORK_IO等待
|
1 2 3 4 |
USE [AdventureWorks] GO SELECT * FROM dbo.[SalesOrderDetail_test] GO 100 |
问题源头 经过排查和这几天的观察情况，确定是某些表缺失索引导致，现在在这些表上增加了索引，问题解决
|
1 2 3 4 5 6 |
select * from t_AccessControl --权限控制表权限控制 select * from t_GroupAccess --用户组权限表用户组权限 select * from t_GroupAccessType --用户组权限类表用户组权限类 select * from t_ObjectAccess --对象权限表对象权限 select * from t_ObjectAccessType --对象权限类型表对象权限类型 select * from t_ObjectType --对象类型表对象类型 |
查询CPU占用高的语句
|
1 2 3 4 5 6 7 8 9 10 11 |
SELECT TOP 10 total_worker_time/execution_count AS avg_cpu_cost, plan_handle, execution_count, (SELECT SUBSTRING(text, statement_start_offset/2 + 1, (CASE WHEN statement_end_offset = -1 THEN LEN(CONVERT(nvarchar(max), text)) * 2 ELSE statement_end_offset END - statement_start_offset)/2) FROM sys.dm_exec_sql_text(sql_handle)) AS query_text FROM sys.dm_exec_query_stats ORDER BY [avg_cpu_cost] DESC |
查询缺失索引
|
1 2 3 4 5 6 |
SELECT DatabaseName = DB_NAME(database_id) ,[Number Indexes Missing] = count(*) FROM sys.dm_db_missing_index_details GROUP BY DB_NAME(database_id) ORDER BY 2 DESC; |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
SELECT TOP 10 [Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0) , avg_user_impact , TableName = statement , [EqualityUsage] = equality_columns , [InequalityUsage] = inequality_columns , [Include Cloumns] = included_columns FROM sys.dm_db_missing_index_groups g INNER JOIN sys.dm_db_missing_index_group_stats s ON s.group_handle = g.index_group_handle INNER JOIN sys.dm_db_missing_index_details d ON d.index_handle = g.index_handle ORDER BY [Total Cost] DESC; |
定位问题后，新建非聚集索引
|
1 2 3 4 5 6 7 |
CREATE NONCLUSTERED INDEX IX_t_AccessControl_F4 ON dbo.t_AccessControl ( FObjectType )include([FUserID], [FAccessType], [FAccessMask]) WITH( STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO drop index IX_t_AccessControl_F4 on t_AccessControl |
CPU占用恢复正常 总结 从多次历史经验来看，如果CPU负载持续很高，但内存和IO都还好的话，这种情况下，首先想到的一定是索引问题，十有八九错不了。 注意文章开头贴出的客户机器负载情况图
View DetailsUber工程师在官方博客上描述了他们为什么要从 Postgres 切换到 MySQL 数据库。Uber的早期架构是由 Python编写的后端应用构成，使用了 Postgres 数据库。但此后，Uber的架构发生了显著的改变，转变到了微服务模型和新的数据平台。以前他们使用 Postgres，现在则改用了基于 MySQL 的数据库分片层。Uber工程师称他们之所以切换到Schemaless和其它基于 MySQL 的后端服务，最主要的原因是Postgres 数据复制效率低下，Postgres更新已有行的效率低于 MySQL，Postgres需要重写每一个行索引，而MySQL只更新改变的索引。 相关链接 MySQL 的详细介绍：请点这里 MySQL 的下载地址：请点这里 from:http://www.oschina.net/news/75638/uber-mysql-migration
View Detailsotter 基于数据库增量日志解析，准实时同步到本机房或异地机房的mysql/oracle数据库. 一个分布式数据库同步系统。 工作原理： 原理描述： 1. 基于Canal开源产品，获取数据库增量日志数据。 什么是Canal, 请点击 2. 典型管理系统架构，manager(web管理)+node(工作节点) a. manager运行时推送同步配置到node节点 b. node节点将同步状态反馈到manager上 3. 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作. osc地址：http://www.oschina.net/p/otter
View DetailsEmoji表情字符现在在APP已经广泛支持了。但是Mysql的UTF8编码对Emoji字符的支持却不是那么好。所以我们经常会遇到这样的异常： Incorrect string value: '\xF0\x90\x8D\x83…' for column 原因是Mysql里UTF8编码最多只能支持3个字节，而Emoji表情字符使用的UTF8编码，很多都是4个字节，有些甚至是6个字节。 解决的方案有两种： 1.使用utf8mb4的mysql编码来容纳这些字符。 2.过滤掉这些特殊的表情字符。 关于第一种解决方法，请参考：http://segmentfault.com/a/1190000000616820 和 http://info.michael-simons.eu/2013/01/21/java-mysql-and-multi-byte-utf-8-support/ 有大量细节需要注意，例如：mysql版本，mysql的配置，mysql connector的版本等等。。 因为我们使用的云数据库，所以我选择了过滤这些特殊字符。其实过滤的方式很简单，直接使用正则表达式匹配编码范围，然后替换就行了。 下面是我的代码。 更多可以参考：http://stackoverflow.com/questions/27820971/why-a-surrogate-java-regexp-finds-hypen-minus import org.apache.commons.lang3.StringUtils; public class EmojiFilterUtils { /** * 将emoji表情替换成* * * @param source * @return 过滤后的字符串 */ public static String filterEmoji(String source) { if(StringUtils.isNotBlank(source)){ return source.replaceAll("[\\ud800\\udc00-\\udbff\\udfff\\ud800-\\udfff]", "*"); }else{ return source; } } public static void main(String[] arg ){ try{ String text = "This is a smiley \uD83C\uDFA6 face\uD860\uDD5D \uD860\uDE07 \uD860\uDEE2 \uD863\uDCCA \uD863\uDCCD \uD863\uDCD2 \uD867\uDD98 "; System.out.println(text); System.out.println(text.length()); System.out.println(text.replaceAll("[\\ud83c\\udc00-\\ud83c\\udfff]|[\\ud83d\\udc00-\\ud83d\\udfff]|[\\u2600-\\u27ff]", "*")); System.out.println(filterEmoji(text)); }catch (Exception ex){ ex.printStackTrace(); } } } from:http://blog.csdn.net/shootyou/article/details/44852639
View Details数据库作为业务的核心，在整个基础软件栈中是非常重要的一环。近几年社区也是新的方案和思想层出不穷，接下来我将总结一下近几年一些主流的开源数据库方案，其背后的设计思想以及适用场景。本人才疏学浅如有遗漏或者错误请见谅。本次分享聚焦于数据库既结构化数据存储 OLTP 及 NoSQL 领域，不会涉及 OLAP、对象存储、分布式文件系统。 1 开源RDBMS与互联网的崛起 很长时间以来，关系型数据库一直是大公司的专利，市场被 Oracle / DB2 等企业数据库牢牢把持。但是随着互联网的崛起、开源社区的发展，上世纪九十年代 MySQL 1.0 的发布，标志着关系型数据库的领域社区终于有可选择的方案。 MySQL 第一个介绍的单机RDBMS就是MySQL。相信大多数朋友都已经对 MySQL 非常熟悉，基本上 MySQL 的成长史就是互联网的成长史。我接触的第一个 MySQL 版本是 MySQL 4.0，到后来的 MySQL 5.5 更是经典——基本所有的互联网公司都在使用。 MySQL 也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是 MySQL tuning 的一个重要的方式。比如对于有事务需求的场景使用 InnoDB;对于并发读取的场景 MyISAM 可能比较合适;但是现在我推荐绝大多数情况还是使用 InnoDB，毕竟 5.6 后已经成为了官方的默认引擎。大多数朋友都基本知道什么场景适用 MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。 另外值得一提的是 MySQL 5.6中引入了多线程复制和 GTID，使得故障恢复和主从的运维变得比较方便。另外，5.7(目前处于 GA 版本) 是 MySQL 的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。MySQL 5.7 MTS支持两种模式，一种是和5.6一样，另一种则是基于binlog group commit实现的多线程复制，也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply，实现并行复制)。 如果有单机数据库技术选型的朋友，基本上只需要考虑 5.7 或者 MariaDB 就好了，而且 5.6、5.7 由 Oracle 接手后，性能和稳定性上都有了明显的提升。 PostgreSQL PostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的 Michael Stronebraker 于 2015 年获得图灵奖。后来项目更名为 Post-Ingres，项目基于 BSD license 下开源。 1995 年几个 UCB 的学生为 Post-Ingres 开发了 SQL 的接口，正式发布了 PostgreSQL95，随后一步步在开源社区中成长起来。 和 MySQL 一样，PostgreSQL 也是一个单机的关系型数据库，但是与 MySQL […]
View Details没有什么东西是一成不变的，包含我们的理想和生活！MySQL作为一个免费的开源的关系型数据库，深受大家喜爱，从最初的无人问津到当下的去IOE，都体现出了MySQL举足轻重的作用。今天我们就从淘宝的发展来阐述MySQL在大型网站下的架构演变史！ MySQL的可扩展性 架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种 Scale-up : 纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力 Scale-out : 横向扩展, 通过加节点（机器）来实现伸缩，提升服务能力 对于互联网的高并发应用来说，无疑Scale out才是出路，通过纵向的买更高端的机器一直是我们所避讳的问题，也不是长久之计，在scale out的理论下，可扩展性的理想状态是什么？ 可扩展性的理想状态 一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态！ MySQL架构的演变 MySQL简单网站架构(V1.0) 一个简单的小型网站或者应用背后的架构可以非常简单, 数据存储只需要一个mysql instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个时间段的网站，一般会把所有的信息存到一个database instance里面。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 1.数据量的总大小 一个机器放不下时 2.数据的索引（B+ Tree）一个机器的内存放不下时 3.访问量(读写混合)一个实例不能承受 只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。 从此我们可以看出，事实上对于很多小公司小应用，这种架构已经足够满足他们的需求了，初期数据量的准确评估是杜绝过度设计很重要的一环，毕竟没有人愿意为不可能发生的事情而浪费自己的经历。 这里简单举个我的例子，对于用户信息这类表 （3个索引），16G内存能放下大概2000W行数据的索引，简单的读和写混合访问量3000/s左右没有问题，你的应用场景是否 MySQL的垂直架构(V2.0) 一般当V1.0 遇到瓶颈时，首先最简便的拆分方法就是垂直拆分，何谓垂直？就是从业务角度来看，将关联性不强的数据拆分到不同的instance上，从而达到消除瓶颈的目标。以图中的为例，将用户信息数据，和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景，我们还可以加一层cache，来减少对DB的压力。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 单实例单业务，依然存在V1.0所述瓶颈，遇到瓶颈时可以考虑往本文更高V版本升级, 若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级 MySQL的主从架构(V3.0) 此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在Mysql的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 写入量主库不能承受 MySQL的路由多集群架构(V4.0) 对于V2.0 V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图Userinfo的拆分为例，将userinfo拆分为3个cluster，每个cluster持有总量的1/3数据，3个cluster数据的总和等于一份完整数据（注：这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群） 数据如何路由？ 1.Range拆分 sharding key按连续区间段路由，一般用在有严格自增ID需求的场景上，如Userid, Userid Range的小例子：以userid 3000W 为Range进行拆分 1号cluster userid 1-3000W 2号cluster userid 3001W-6000W 2.List拆分 List拆分与Range拆分思路一样，都是通过给不同的sharding key来路由到不同的cluster,但是具体方法有些不同,List主要用来做sharding key不是连续区间的序列落到一个cluster的情况，如以下场景： 假定有20个音像店，分布在4个有经销权的地区，如下表所示： 业务希望能够把一个地区的所有数据组织到一起来搜索，这种场景List拆分可以轻松搞定 3.Hash拆分 通过对sharding key 进行哈希的方式来进行拆分，常用的哈希方法有除余,字符串哈希等等，除余如按userid%n 的值来决定数据读写哪个cluster，其他哈希类算法这里就不细展开讲了。 数据拆分后引入的问题： 数据水平拆分引入的问题主要是只能通过sharding key来读写操作，例如以userid为sharding key的切分例子，读userid的详细信息时，一定需要先知道userid,这样才能推算出再哪个cluster进而进行查询，假设我需要按username进行检索用户信息，需要引入额外的反向索引机制（类似HBASE二级索引），如在redis上存储username->userid的映射，以username查询的例子变成了先通过查询username->userid，再通过userid查询相应的信息。 实际上这个做法很简单，但是我们不要忽略了一个额外的隐患，那就是数据不一致的隐患。存储在redis里的username->userid和存储在mysql里的userid->username必须需要是一致的，这个保证起来很多时候是一件比较困难的事情，举个例子来说，对于修改用户名这个场景，你需要同时修改redis和mysql,这两个东西是很难做到事务保证的,如mysql操作成功 但是redis却操作失败了（分布式事务引入成本较高）,对于互联网应用来说，可用性是最重要的，一致性是其次，所以能够容忍小量的不一致出现. 毕竟从占比来说，这类的不一致的比例可以微乎其微到忽略不计（一般写更新也会采用mq来保证直到成功为止才停止重试操作） 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 在这个拆分理念上搭建起来的架构，理论上不存在瓶颈（sharding key能确保各cluster流量相对均衡的前提下),不过确有一件恶心的事情，那就是cluster扩容的时候重做数据的成本，如我原来有3个cluster，但是现在我的数据增长比较快，我需要6个cluster，那么我们需要将每个cluster 一拆为二，一般的做法是 1.摘下一个slave,停同步, 2.对写记录增量log（实现上可以业务方对写操作 多一次写持久化mq 或者mysql主创建trigger记录写 等等方式） […]
View Details一.数值类型 Mysql支持所有标准SQL中的数值类型，其中包括严格数据类型(INTEGER,SMALLINT,DECIMAL,NUMBERIC)，以及近似数值数据类型(FLOAT,REAL,DOUBLE PRESISION),并在此基础上进行扩展。 扩展后增加了TINYINT,MEDIUMINT,BIGINT这3种长度不同的整形，并增加了BIT类型，用来存放位数据。 整数类型 字节 范围（有符号） 范围（无符号） 用途 TINYINT 1字节 (-128，127) (0，255) 小整数值 SMALLINT 2字节 (-32 768，32 767) (0，65 535) 大整数值 MEDIUMINT 3字节 (-8 388 608，8 388 607) (0，16 777 215) 大整数值 INT或INTEGER 4字节 (-2 147 483 648，2 147 483 647) […]
View Details使用EF设计器 此时此刻，发现二逼了，咋没有MySQL Database呢？ 好吧，下面重点： 需要下载安装： 1：mysql-for-visualstudio-1.2.6.msi http://dev.mysql.com/downloads/file/?id=460645 2：mysql-connector-net-6.9.8.msi http://dev.mysql.com/downloads/connector/net/ 3：使用Nuget安装EF 我这边是已经安装完了（版本选择6.1以上的），所以显示“更新”和“卸载”，如果你安装了，继续看下面的 下图是随便找了一个没安装的，就会有“安装”按钮， 4：使用Nuget安装Mysql.Data.Entity 与安装EF相同 点击安装后，一会会出现如下图： 执行完上述步骤，看web.config文件，会自动增加如下代码 OK,现在我们所有的步骤就执行完了。最好重启下VS（不知道是不是必须，反正我重启了），之后重新编译。 再之后，就可以按开始的步骤生成MYSQL对应的实体了。 注：如果刚开始那两个MSI文件安装有问题，则生成实体的时候，到了这一步之后（如下图），会出现闪退问题，无法生成实体 （本人就遇到过这个问题） 到了这一步，已经没有任何悬念了。 来自为知笔记(Wiz) from:http://www.cnblogs.com/RushPasser/p/5438334.html
View Details