MySQL索引及执行计划

一.索引作用

提供了类似于书中目录的作用，目的是为了优化查询

二.索引的种类

B树索引  Hash索引  R树索引  Full text   GIS

三.B树基于不同的查找算法分类介绍

B-tree

B+tree    在范围查询方面提供了更好的性能 （> < >= <=）

B*tree 

四.在功能上的分类

4.1辅助索引（s）怎么构建B树结构的？

1） 索引是基于表中，列（索引建）的值生成的B树结构

2）首先提取此列的所有值，进行自动排序

3）将排好序的值，均匀分布到索引树的叶子节点中(16k)

4）然后生成此索引的键值所对应的后端数据页的指针

5）生成枝节点和根节点，根据数据量级和索引键长度，生成合适的索引树高度

问题: 基于索引键做where查询,对于id列是顺序IO,但是对于其他列的查询,可能是随机IO.

4.2聚集索引（C）

4.2.1前提

1）表中设置了主键，主键列就会自动被作为聚集索引

2）如果没有主键，会选择唯一键作为聚集索引

3）聚集索引必须在建表时才有意义，一般是表的无关列（ID）

4）聚集索引在叶子节点上是整行的数据（辅助索引仅是提取列的值进行排序）

4.2.2辅助索引（s）怎么构建B树结构的

1）在建表时，设置了主键列（ID）

2）在将来录入数据时，就会按照ID列的顺序存储到磁盘上（又称之为聚集索引组织表）

3）将排好序的整行数据，生成叶子节点，可以理解为，磁盘的数据页就是叶子节点

（因为聚集索引是在创建表的时候就将每一行的内容进行了排序生成了叶子节点。因此在将来存储的时候就会按照这个顺序进行存储。而辅助索引只是某一列的值进行排列。）

五.辅助索引细分

1.普通的单列辅助索引

2.覆盖索引（联合索引）：多个列作为索引条件,生成索引树,理论上设计的好的,可以减少大量的回表查询

3.唯一索引 : 索引列的值都是唯一的

六.索引树的高度受什么影响

1.数据量级，解决方法：分表，分库，分布式

2.索引列值过长，解决方法：前缀索引

3.数据类型

变长长度的字符串，使用了char，解决方案：边长字符串使用varchar

enum类型的使用 ('山东','河北','黑龙江','吉林','辽宁','陕西'......) 1  2  3

七.索引的基本管理

7.1索引的建立前

db01 [world]>desc city;

+-------------+----------+------+-----+---------+----------------+

| Field       | Type     | Null | Key | Default | Extra          |

+-------------+----------+------+-----+---------+----------------+

Field :列名字

key  :有没有索引,索引类型

  PRI: 主键索引

  UNI: 唯一索引

  MUL: 辅助索引(单列,联和,前缀)

7.1.单列普通辅助索引

7.1.1创建索引

alter table 表 add index  索引名（列名）  

例：  alter table city add index idx_name(name);

show index from city;（查看表的索引名）

注：同一个表中，索引名不能同名。同时在生产操作中，不建议在一个列上建多个索引

7.1.2删除索引：

alter table 表名 drop index 索引名

例：alter table city drop index idx_name1;

7.2覆盖索引（联合索引）

alter table  表名 add  index  索引名（列名，列名）

例：alter table city add index idx_co_po(countrycode,population);

7.3前缀索引

alter table  表名 add index  索引名（列名（前几个字符））

例：alter table city add index idx_di(district(5));

7.4 唯一索引

db01 [world]>alter table city add unique index idx_uni1(name);

ERROR 1062 (23000): Duplicate entry 'San Jose' for key 'idx_uni1'

统计city表中，以省的名字为分组，统计组的个数

select district,count(id) from city group by district;

需求: 找到world下,city表中 name列有重复值的行,最后删掉重复的行

db01 [world]>select name,count(id) as cid from city group by name  having cid>1 order by cid desc;

db01 [world]>select * from city where name='suzhou';

===============================================

八. 执行计划获取及分析

8.0 介绍

(1)

获取到的是优化器选择完成的,他认为代价最小的执行计划.

作用: 语句执行前,先看执行计划信息,可以有效的防止性能较差的语句带来的性能问题.

如果业务中出现了慢语句，我们也需要借助此命令进行语句的评估，分析优化方案。

(2) select 获取数据的方法

1. 全表扫描(应当尽量避免,因为性能低)

2. 索引扫描

3. 获取不到数据

8.1 执行计划获取

获取优化器选择后的执行计划

8.2 执行计划分析

8.2.0 重点关注的信息

table: city                               ---->查询操作的表    **

possible_keys: CountryCode,idx_co_po      ---->可能会走的索引  **

key: CountryCode   ---->真正走的索引    ***

type: ref   ---->索引类型        *****

Extra: Using index condition              ---->额外信息        *****

8.2.1 type详解

从左到右性能依次变好.

ALL,index,range,ref,eq_ref,system(const),NULL（*****）

(1) ALL: 代表的是全表扫描

desc select * from city;

desc select * from city where name like '%C%';

desc select * from city where name != 'CHN';

desc select * from city where countrycode not in ('CHN','USA');

注意：生产中几乎是没有这种需求的。尽量避免

(2) index: 全索引扫描

需要扫描整个索引树,获取到想要数据,比ALL性能好,顺序IO,可以减少回表查询

db01 [world]>desc select name from city;

(3) range : 索引范围查询

>  <  >= <=

in

or

like 'CH%'

between and

db01 [world]>desc select * from city where id<10;

db01 [world]>desc select * from city where countrycode like 'CH%';

B+树额外优化:

> < >= <=

between and

like 'CH%'

in or无法享受B+树的额外优化,可以用union all来替代

例：查看中国和美国的城市信息

SELECT * FROM city WHERE countrycode='CHN' OR countrycode='USA';

或者：

SELECT * FROM city WHERE countrycode='CHN'

UNION ALL

SELECT * FROM city WHERE countrycode='USA'

(4) ref: 辅助索引的等值查询

db01 [world]>desc select * from city where countrycode = 'CHN';

+----+-------------+-------+------------+------+-----------------------+-------------+---------+-------+------+----------+-------+

| id | select_type | table | partitions | type | possible_keys         | key         | key_len | ref   | rows | filtered | Extra |

+----+-------------+-------+------------+------+-----------------------+-------------+---------+-------+------+----------+-------+

|  1 | SIMPLE      | city  | NULL       | ref  | CountryCode,idx_co_po | CountryCode | 3       | const |  363 |   100.00 | NULL  |

+----+-------------+-------+------------+------+-----------------------+-------------+---------+-------+------+----------+-------+

db01 [world]>desc select * from city where countrycode in ('CHN','USA');

db01 [world]>desc select * from city where countrycode='CHN'

    -> union all

    -> select * from city where countrycode='USA';

(5) eq_ref :多表连接的表,On的条件是主键或唯一键

desc select city.name,country.name

 from city 

join country 

on city.countrycode=country.code

 where city.population<100\G

(6) system 或 const :主键或唯一键的等值查询

db01 [world]>desc select * from city where id=10;

(7) NULL , 索引中扫描不到这个数据

db01 [world]>desc select * from city where id=5000;

结论：在索引扫描类型方面，至少保证在range以上级别。

============================

8.2.2 其他字段解释

Extra:

  Using filesort（关注）

意思是在查询过程中又一次启用了排序的功能*因为索引在构造B+树的时候本身就进行了一次排列，数据已经是有序的了。如果出现 Using filesort 则说名 索引是有问题的。 

**** 统一优化方法 把该列与前面where 条件的列进行一个联合索引。

desc select * from city where countrycode='CHN' order by population desc limit 10;

+----+-------------+-------+------+---------------+-------------+---------+-------+------+----------------------------------------------------+

| id | select_type | table | type | possible_keys | key         | key_len | ref   | rows | Extra                                              |

+----+-------------+-------+------+---------------+-------------+---------+-------+------+----------------------------------------------------+

|  1 | SIMPLE      | city  | ref  | CountryCode   | CountryCode | 3       | const |  363 | Using index condition; Using where; Using filesort |

+----+-------------+-------+------+---------------+-------------+---------+-------+------+--------------------------

db01 [world]>alter table city add index idx_po(countrycode,population);

db01 [world]>desc select * from city where countrycode='CHN' order by population limit 10;

解决思路：

索引可以减少排序,可以很大程度减少CPU时间

辅助索引 应用顺序(优化器选择的)

如果查询条件:符合覆盖索引的顺序时,优先选择覆盖索引

不符合顺序,优先会走where条件的索引

优化方法,将where列和order列建立联合索引

alter table city add index idx_co_po(countrycode,population);

6.2.3 explain(desc)使用场景（面试题）

SQL语句有问题，

题目意思:  我们公司业务慢,请你从数据库的角度分析原因

1.mysql出现性能问题,我总结有两种情况:

（1）应急性的慢：突然夯住

应急情况:数据库hang(卡了,资源耗尽)

处理过程:

1.show full  processlist;   获取到导致数据库hang的语句

额外关注一个time ，语句执行时间。通常有问题的SQL语句执行时间都会很长

2. explain 分析SQL的执行计划,有没有走索引,索引的类型情况

3. 建索引,改语句

（2）一段时间慢(持续性的):

(1)记录慢日志slowlog,分析slowlog

(2)explain 分析SQL的执行计划,有没有走索引,索引的类型情况

 (3)建索引,改语句

九. 索引效果压力测试

===========压力测试===========

1、模拟数据库数据

drop database if exists oldboy;

create database oldboy charset utf8mb4 collate utf8mb4_bin;

use oldboy;

create table t_100w (id int,num int,k1 char(2),k2 char(4),dt timestamp);

delimiter //

create  procedure rand_data(in num int)

begin

declare str char(62) default 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';

declare str2 char(2);

declare str4 char(4);

declare i int default 0;

while i<num do

set str2=concat(substring(str,1+floor(rand()*61),1),substring(str,1+floor(rand()*61),1));

set str4=concat(substring(str,1+floor(rand()*61),2),substring(str,1+floor(rand()*61),2));

set i=i+1;

insert into t_100w values (i,floor(rand()*num),str2,str4,now());

end while;

end;

//

delimiter ;

插入100w条数据：

call rand_data(1000000);

commit;

2、检查数据可用性

mysql -uroot -p

select count(*) from oldboy. t_100w;

3、在没有优化之前我们使用mysqlslap来进行压力测试

mysqlslap --defaults-file=/etc/my.cnf \

--concurrency=100 --iterations=1 --create-schema='oldboy' \

--query="select * from oldboy.t1 where stuname='alexsb_100'" engine=innodb \

--number-of-queries=2000 -uroot -p123 -verbose

==========================================================

压力测试工具:

tpcc

sysbench

=================================================

十. 索引应用规范

业务：

1.产品的功能

2.用户的行为

"热"查询语句

"热"数据

10.1  建立索引的原则（DBA运维规范）

10.1.0 说明

为了使索引的使用效率更高，在创建索引时，必须考虑在哪些字段上创建索引和创建什么类型的索引。那么索引设计原则又是怎样的?

10.1.1 (必须的) 建表时一定要有主键,一般是个无关列

10.1.2 选择唯一性索引

唯一性索引的值是唯一的，可以更快速的通过该索引来确定某条记录。

例如，学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。

如果使用姓名的话，可能存在同名现象，从而降低查询速度。

优化方案:

(1) 如果非得使用重复值较多的列作为查询条件(例如:男女),可以将表逻辑拆分

(2) 可以将此列和其他的查询类,做联和索引

select count(*) from world.city;

select count(distinct countrycode) from world.city;

select count(distinct countrycode,population ) from world.city;

10.1.3(必须的) 为经常需要where 、ORDER BY、GROUP BY,join on等操作的字段，

排序操作会浪费很多时间。

where  A B C      ----》 A  B  C

in 

如果where A   group by B  order by C

联合索引需要的顺序为 A,B，C

如果为其建立索引，优化查询

注：如果经常作为条件的列，重复值特别多，可以建立联合索引。

10.1.4 尽量使用前缀来索引

如果索引字段的值很长，最好使用值的前缀来索引。

------------------------以上的是重点关注的，以下是能保证则保证的--------------------

10.1.5 限制索引的数目

索引的数目不是越多越好。

可能会产生的问题:

(1) 每个索引都需要占用磁盘空间，索引越多，需要的磁盘空间就越大。

(2) 修改表时，对索引的重构和更新很麻烦。越多的索引，会使更新表变得很浪费时间。

(3) 优化器的负担会很重,有可能会影响到优化器的选择.

percona-toolkit中有个工具,专门分析索引是否有用

10.1.6 删除不再使用或者很少使用的索引(percona toolkit)

表中的数据被大量更新，或者数据的使用方式被改变后，原有的一些索引可能不再需要。数据库管理

员应当定期找出这些索引，将它们删除，从而减少索引对更新操作的影响。

10.1.7 大表加索引,要在业务不繁忙期间操作

10.1.8 尽量少在经常更新值的列上建索引

10.1.9 建索引原则

(1) 必须要有主键,如果没有可以做为主键条件的列,创建无关列

(2) 经常做为where条件列  order by  group by   join on, distinct 的条件(业务:产品功能+用户行为)

(3) 最好使用唯一值多的列作为索引,如果索引列重复值较多,可以考虑使用联合索引

(4) 列值长度较长的索引列,我们建议使用前缀索引.

(5) 降低索引条目,一方面不要创建没用索引,不常使用的索引清理,percona toolkit(xxxxx)

(6) 索引维护要避开业务繁忙期

===============================================

10.2 不走索引的情况（开发规范）

10.2.1 没有查询条件，或者查询条件没有建立索引

select * from tab;       全表扫描。

select  * from tab where 1=1;

在业务数据库中，特别是数据量比较大的表。

是没有全表扫描这种需求。

1、对用户查看是非常痛苦的。

2、对服务器来讲毁灭性的。

（1）select * from tab;

SQL改写成以下语句：

select  * from  tab  order by  price  limit 10 ;     需要在price列上建立索引

（2）

select  * from  tab where name='zhangsan'          name列没有索引

改：

1、换成有索引的列作为查询条件

2、将name列建立索引

10.2.2 查询结果集是原表中的大部分数据，应该是25％以上。

查询的结果集，超过了总数行数25%，优化器觉得就没有必要走索引了。

假如：tab表 id，name    id:1-100w  ，id列有(辅助)索引

select * from tab  where id>500000;

如果业务允许，可以使用limit控制。

怎么改写 ？

结合业务判断，有没有更好的方式。如果没有更好的改写方案

尽量不要在mysql存放这个数据了。放到redis里面。

10.2.3  索引本身失效，统计数据不真实

索引有自我维护的能力。

对于表内容变化比较频繁的情况下，有可能会出现索引失效。

一般是删除重建

10.2.4 查询条件使用函数在索引列上，或者对索引列进行运算，运算包括(+，-，*，/，! 等)

例子：

错误的例子：select * from test where id-1=9;

正确的例子：select * from test where id=10;

算术运算

函数运算

子查询

10.2.5  隐式转换导致索引失效.这一点应当引起重视.也是开发中经常会犯的错误.

这样会导致索引失效. 错误的例子：

mysql> alter table tab add index inx_tel(telnum);

Query OK, 0 rows affected (0.03 sec)

Records: 0  Duplicates: 0  Warnings: 0

mysql>

mysql> desc tab;

+--------+-------------+------+-----+---------+-------+

| Field  | Type        | Null | Key | Default | Extra |

+--------+-------------+------+-----+---------+-------+

| id     | int(11)     | YES  |     | NULL    |       |

| name   | varchar(20) | YES  |     | NULL    |       |

| telnum | varchar(20) | YES  | MUL | NULL    |       |

+--------+-------------+------+-----+---------+-------+

3 rows in set (0.01 sec)

mysql> select * from tab where telnum='1333333';

+------+------+---------+

| id   | name | telnum  |

+------+------+---------+

|    1 | a    | 1333333 |

+------+------+---------+

1 row in set (0.00 sec)

mysql> select * from tab where telnum=1333333;

+------+------+---------+

| id   | name | telnum  |

+------+------+---------+

|    1 | a    | 1333333 |

+------+------+---------+

1 row in set (0.00 sec)

mysql> explain  select * from tab where telnum='1333333';

+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra                 |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

|  1 | SIMPLE      | tab   | ref  | inx_tel       | inx_tel | 63      | const |    1 | Using index condition |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

1 row in set (0.00 sec)

mysql> explain  select * from tab where telnum=1333333;

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | tab   | ALL  | inx_tel       | NULL | NULL    | NULL |    2 | Using where |

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

1 row in set (0.00 sec)

mysql> explain  select * from tab where telnum=1555555;

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra       |

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | tab   | ALL  | inx_tel       | NULL | NULL    | NULL |    2 | Using where |

+----+-------------+-------+------+---------------+------+---------+------+------+-------------+

1 row in set (0.00 sec)

mysql> explain  select * from tab where telnum='1555555';

+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra                 |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

|  1 | SIMPLE      | tab   | ref  | inx_tel       | inx_tel | 63      | const |    1 | Using index condition |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-----------------------+

1 row in set (0.00 sec)

mysql>

---------------------------------------

10.2.6  <>  ，not in 不走索引（辅助索引）

EXPLAIN  SELECT * FROM teltab WHERE telnum   <> '110';

EXPLAIN  SELECT * FROM teltab WHERE telnum  NOT IN ('110','119');

------------

mysql> select * from tab where telnum <> '1555555';

+------+------+---------+

| id   | name | telnum  |

+------+------+---------+

|    1 | a    | 1333333 |

+------+------+---------+

1 row in set (0.00 sec)

mysql> explain select * from tab where telnum <> '1555555';

-----

单独的>,<,in 有可能走，也有可能不走，和结果集有关，尽量结合业务添加limit

or或in  尽量改成union

EXPLAIN  SELECT * FROM teltab WHERE telnum   IN ('110','119');

改写成：

EXPLAIN SELECT * FROM teltab WHERE telnum='110'

UNION ALL

SELECT * FROM teltab WHERE telnum='119'

-----------------------------------

10.2.7  like "%_" 百分号在最前面不走

EXPLAIN SELECT * FROM teltab WHERE telnum LIKE '31%'   走range索引扫描

EXPLAIN SELECT * FROM teltab WHERE telnum LIKE '%110'  不走索引

%linux%类的搜索需求，可以使用elasticsearch+mongodb 专门做搜索服务的数据库产品

作者：wwwoldguocom

链接：https://www.jianshu.com/p/3621e36cf0af

来源：简书

简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 160,165评论 4赞 364
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 67,720评论 1赞 298
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 109,849评论 0赞 244
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 44,245评论 0赞 213
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 52,596评论 3赞 288
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 40,747评论 1赞 222
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 31,977评论 2赞 315
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 30,708评论 0赞 204
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 34,448评论 1赞 246
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,657评论 2赞 249
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,141评论 1赞 261
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 28,493评论 3赞 258
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 33,153评论 3赞 238
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,108评论 0赞 8
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,890评论 0赞 198
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 35,799评论 2赞 277
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 35,685评论 2赞 272

推荐阅读更多精彩内容

  • MYSQL基础
    MYSQL 基础知识 1 MySQL数据库概要 2 简单MySQL环境 3 数据的存储和获取 4 MySQL基本操...
    Kingtester阅读 7,651评论 5赞 116
  • 数据库性能优化详解
    转 # https://www.cnblogs.com/easypass/archive/2010/12/ 08/...
    吕品㗊阅读 9,620评论 0赞 44
  • sql
    50个常用的sql语句Student(S#,Sname,Sage,Ssex) 学生表Course(C#,Cname...
    哈哈海阅读 1,207评论 0赞 7
  • 数据库
    常用语句： sql/plus sqlplus 'amdocs/Amdocs.Jx.China.110#@ysdb1...
    好好学习的蜗牛阅读 2,858评论 0赞 0
  • 诗歌·冬
    祭·冬 这个冬天似乎得了重感冒 围巾在脖子上呛得她咳嗽 行人叽叽喳喳让她烦躁 湖边芦苇睡的安详 天上凑热闹的躲在一...
    墨须游阅读 97评论 9赞 6