渣渣小本求职复习之路每天一博客系列——数据库基础(MySQL)(3)

      前情回顾:通过复习数据定义和数据更新,我们重温了如何定义数据库文件、创建数据库、建立基本表,以及对基本表中的数据进行增删改的SQL语法。(不过还是要多练习,光看是不行,到时候很可能就写不出来。)

      从昨天开始就有点重感冒,没想到今天一大早起来竟然越来越严重了,把舍友的卫生纸用了大半包不说,因为咽喉痛还到隔壁接了不下五瓶纯净水,喝得自己有点反胃。天气转凉,大家要注意身体了,不要像我一样成了鼻涕兽。

—————————————————————————闲聊结束———————————————————————————————

第五章:查询、视图与索引

      第一节:查询

      我们先贴出最简单的SELECT语法:

SELECT [DISTINCT]{*,column[alias],...}//DISTINCT关键字表示消除重复行
FROM    table

  再看看SELECT中的WHERE语法:

SELECT     [DISTINCT]{*,column[alias],...}//DISTINCT关键字表示消除重复行
FROM        table
[WHERE    condition(s)]

      在WHERE子句中,我们常常会使用比较运算符,有一些会比较特殊,例如BETWEEN...AND...、IN(list)、LIKE(与一个范式作匹配)、以及IS NULL(是一个空值)。还有逻辑运算符,例如AND、OR、NOT。那么这些运算符号的优先级是怎样的呢?比较运算符优先级最高,NOT次之,AND再次之,OR最低。

      接下来快速看几个语句:

排序语句ORDER BY——根据某一列排序,默认升序(ASC),在最后接DESC则是降序。

字符串函数——“+”两字符串连接,LENT(str)求出长度,CHARINDEX(‘{CHAR}’,str)求出字符的索引,SUBSTRING求子字符串。

多表连接运算——“=”等值连接(去掉重复的属性列则属于自然连接),LEFT OUTER JOIN(左外连接)、RIGHT OUTER JOIN(右外连接)

分组函数(忽略空值)——AVG求平均值,SUM求和,MIN求最小值,MAX求最大值,COUNT求非空行的计数

分组语句GROUP BY——将表中的数据分成小组。(不在分组函数中的列必须在GROUP BY语句中出现)

限制组语句HAVING——限制分组内容的输出,不能用WHERE语句,只能用HAVING语句。

     (由于我都看了课件,这些东西又比较基础,就不一一举例说明了,有遗忘的童鞋可以百度一下)

      第二节:视图

      为什么要使用视图呢?有以下几点原因:

1.限制数据访问

2.简化用户操作,使得复杂查询简单化

3.使用户能以多种角度看待同一数据

4.对重构数据库提供了一定程度的逻辑独立性

5.对机密数据提供安全保护

       创建视图,无非就是嵌入一个子查询在CREATE VIEW语句中:

CREATE VIEW view
AS subquery
[WITH CHECK OPTION]

        子查询可以包含复杂的SELECT语法,但是,不能包含ORDERBY子句!(这是为什么呢?)

        在视图上操作的时候,在简单视图上可以进行DML operations(也就是SELECT、UPDATE、INSERT、DELETE)。但是在下列情况下则不能进行增删改等操作。

1.GROUP函数、GROUP BY语句、DISTINCT关键字

2.有非空列没有出现在视图定义中

3.视图中有表达式定义的列

4.视图定义中有嵌套查询,并且内层查询中的from子句涉及的表也是导出该视图的基本表

5.一个不允许更新的视图上定义的视图也不允许更新

         删除视图的操作:DROP VIEW view

         第三节:索引

         索引有什么用呢?建立索引是为了加快查询速度,有些DBMS会自动建立以下列上的索引:PRIMARY KEY和UNIQUE。至于维护索引和使用索引,这些不用我们管,都是DBMS自动完成以及自动选择是否使用、使用哪些索引。

         那么,如何建立索引呢?

         unique(distinct):唯一性索引,不允许表中不同的行在索引列上取相同值。

         clustered:聚簇索引,表中元组按索引项的值排序并物理地聚簇在一起。一个基本表上只能建一个聚簇索引。(适用范围:很少对基本表进行增删操作,很少对其中的变长列进行修改操作)

         那么,在什么情况下需要建立索引呢?

1.在WHERE或连接条件中频繁使用的列

2.在列取值范围较大时

3.列包含大量的非空值

4.查询少于2-4%行的大表

         删除索引:DROP INDEX index-name

 

         接下来,终于要跟MySQL打打交道了。参考资料——《深入浅出MySQL》

第六章:MySQL的存储引擎

      第一节:什么是存储引擎

      MySQL中的数据用各种不同的技术存储在文件(或者内存)中。这些技术中的每一种技术都使用不同的存储机制、索引技巧、锁定水平并且最终提供广泛的不同的功能和能力。通过选择不同的技术,你能够获得额外的速度或者功能,从而改善你的应用的整体功能。这些不同的技术以及配套的相关功能在MySQL中被称作存储引擎(也称作表类型)。

      ——引自《百度百科》

      默认情况下,创建新表如果不指定表的存储引擎,则新表是默认存储引擎的。如果要修改默认存储引擎,则可以采取以下步骤:

1、查看mysql存储引擎命令,在mysql>提示符下搞入show engines;字段 Support为:Default表示默认存储引擎  
2、设置InnoDB为默认引擎:在配置文件my.cnf中的 [mysqld] 下面加入default-storage-engine=INNODB 一句
3、重启mysql服务器:mysqladmin -u root -p shutdown或者service mysqld restart 登录mysql数据库

     引用地址:http://www.cnblogs.com/yjwen/archive/2012/05/01/2478124.html

       第二节:MySQL中支持哪些存储引擎

       首先,我们来了解几个常见的存储引擎(引自百度百科)

MyISAM: Mysql的默认数据库,最为常用。拥有较高的插入,查询速度,但不支持事务
InnoDB :事务型数据库的首选引擎,支持ACID事务,支持行级锁定
BDB: 源自Berkeley DB,事务型数据库的另一种选择,支持COMMIT和ROLLBACK等其他事务特性
Memory :所有数据置于内存的存储引擎,拥有极高的插入,更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失
Merge :将一定数量的MyISAM表联合而成一个整体,在超大规模数据存储时很有用
BlackHole :黑洞引擎,写入的任何数据都会消失,一般用于记录binlog做复制的中继
       听说Mysql的存储引擎接口定义不错,如果以后有机会的话可以试着写写自己专用的存储引擎。

      (在这里,只是简单地介绍而已,更多了解的内容,再次给大家推荐一本参考书——《深入浅出MySQL》,相当不错)

       第三节:如何选择合适的存储引擎

       不同的存储引擎是根据不同的需要设计的,那么选择不同的存储引擎时,最重要的就是根据不同的特点选择最合乎自身需要的存储引擎。

       (以下的介绍,均引自http://isky000.com/database/mysql-performance-tuning-storage-engine)

MyISAM

1.特性

  不支持事务:MyISAM存储引擎不支持事务,所以对事务有要求的业务场景不能使用

  表级锁定:其锁定机制是表级索引,这虽然可以让锁定的实现成本很小但是也同时大大降低了其并发性能

  读写互相阻塞:不仅会在写入的时候阻塞读取,MyISAM还会在读取的时候阻塞写入,但读本身并不会阻塞另外的读

  只会缓存索引:MyISAM可以通过key_buffer缓存以大大提高访问性能减少磁盘IO,但是这个缓存区只会缓存索引,而不会缓存数据

2.适用场景

  不需要事务支持(不支持)

  并发相对较低(锁定机制问题)

  数据修改相对较少(阻塞问题)

  以读为主

  数据一致性要求不是非常高

3.最佳实践

  尽量索引(缓存机制)

  调整读写优先级,根据实际需求确保重要操作更优先

  启用延迟插入改善大批量写入性能

  尽量顺序操作让insert数据都写入到尾部,减少阻塞

  分解大的操作,降低单个操作的阻塞时间

  降低并发数,某些高并发场景通过应用来进行排队机制

  对于相对静态的数据,充分利用Query Cache可以极大的提高访问效率

  MyISAM的Count只有在全表扫描的时候特别高效,带有其他条件的count都需要进行实际的数据访问

 

InnoDB

1.特性

  具有较好的事务支持:支持4个事务隔离级别,支持多版本读

  行级锁定:通过索引实现,全表扫描仍然会是表锁,注意间隙锁的影响

  读写阻塞与事务隔离级别相关

  具有非常高效的缓存特性:能缓存索引,也能缓存数据

  整个表和主键以Cluster方式存储,组成一颗平衡树

  所有Secondary Index都会保存主键信息

2.适用场景

  需要事务支持(具有较好的事务特性)

  行级锁定对高并发有很好的适应能力,但需要确保查询是通过索引完成

  数据更新较为频繁的场景

  数据一致性要求较高

  硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,尽可能减少磁盘 IO

3.最佳实践

  主键尽可能小,避免给Secondary index带来过大的空间负担

  避免全表扫描,因为会使用表锁

  尽可能缓存所有的索引和数据,提高响应速度

  在大批量小插入的时候,尽量自己控制事务而不要使用autocommit自动提交

  合理设置innodb_flush_log_at_trx_commit参数值,不要过度追求安全性

  避免主键更新,因为这会带来大量的数据移动

 

NDBCluster

1.特性

  分布式:分布式存储引擎,可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分

  支持事务:和Innodb一样,支持事务

  可与mysqld不在一台主机:可以和mysqld分开存在于独立的主机上,然后通过网络和mysqld通信交互

  内存需求量巨大:新版本索引以及被索引的数据必须存放在内存中,老版本所有数据和索引必须存在与内存中

2.适用场景

  具有非常高的并发需求

  对单个请求的响应并不是非常的critical

  查询简单,过滤条件较为固定,每次请求数据量较少,又不希望自己进行水平Sharding

3.最佳实践

  尽可能让查询简单,避免数据的跨节点传输

  尽可能满足SQL节点的计算性能,大一点的集群SQL节点会明显多余Data节点

  在各节点之间尽可能使用万兆网络环境互联,以减少数据在网络层传输过程中的延时

 

      班里的一个同学,在腾讯二面的时候就被问到了MySQL存储引擎的问题。

—————————————————————————第九天——————————————————————————

      还是说几句吧。

1.这篇博客引用了好多其他前辈写的博客,写完之后觉得有一点点怪怪的,下次争取吸收之后,根据自己的理解,用自己的话,从新写出来。

2.第一次没把博客发首页,不知道有多少人会看到呢。谢谢看到这篇博客的朋友的支持,也很希望你们能够给我留言鼓劲加油,如果能有批评建议就更好了!

3.十一月马上就要到,自己的生日也快了。我从小都不过生日,过生日指的是聚餐庆祝吃蛋糕收礼物什么的,自从十八岁成年开始,每年都会自己很期待自己的生日。我觉得自己能送给自己最好的生日礼物就是成长起来,让自己和身边的人越来越开心。坚持写博客,让自己成长。

     

      

posted @ 2013-10-27 20:28  LevenYes  阅读(385)  评论(2编辑  收藏  举报