一)连接MYSQL:
格式:mysql-h主机地址-u用户名-p用户密码
1、例1:连接到本机上的MYSQL
首先在打开DOS窗口,然后进入mysql安装目录下的bin目录下,例如:D:mysqlin,再键入命令mysql-uroot-p,回车后提示你输密码,如果刚安装好MYSQL,超级用户root是没有密码的,故直接回车即可进入到MYSQL中了,MYSQL的提示符是:mysql>
2、例2:连接到远程主机上的MYSQL
假设远程主机的IP为:10001,用户名为root,密码为123。则键入以下命令:
mysql-h10001-uroot-p123
(注:u与root可以不用加空格,其它也一样)
3、退出MYSQL命令
exit(回车)
(二)修改密码:
格式:mysqladmin-u用户名-p旧密码password新密码
1、例1:给root加个密码123。首先在DOS下进入目录C:mysqlin,然后键入以下命令:
mysqladmin-uroot-password123
注:因为开始时root没有密码,所以-p旧密码一项就可以省略了。
2、例2:再将root的密码改为456
mysqladmin-uroot-pab12password456
(三)增加新用户:(注意:和上面不同,下面的因为是MYSQL环境中的命令,所以后面都带一个分号作为命令结束符)
格式:grantselecton数据库to用户名@登录主机identifiedby"密码"
例1、增加一个用户test1密码为abc,让他可以在任何主机上登录,并对所有数据库有查询、插入、修改、删除的权限。首先用以root用户连入MYSQL,然后键入以下命令:
grantselect,insert,update,deleteontotest1@"%"Identifiedby"abc";
但例1增加的用户是十分危险的,你想如某个人知道test1的密码,那么他就可以在internet上的任何一台电脑上登录你的mysql数据库并对你的数据可以为所欲为了,解决办法见例2。
例2、增加一个用户test2密码为abc,让他只可以在localhost上登录,并可以对数据库mydb进行查询、插入、修改、删除的 *** 作(localhost指本地主机,即MYSQL数据库所在的那台主机),这样用户即使用知道test2的密码,他也无法从internet上直接访问数据库,只能通过MYSQL主机上的web页来访问了。
grantselect,insert,update,deleteonmydbtotest2@localhostidentifiedby"abc";
如果你不想test2有密码,可以再打一个命令将密码消掉。
grantselect,insert,update,deleteonmydbtotest2@localhostidentifiedby"";
(四)显示命令
1、显示数据库列表:
showdatabases;
刚开始时才两个数据库:mysql和test。mysql库很重要它里面有MYSQL的系统信息,我们改密码和新增用户,实际上就是用这个库进行 *** 作。
2、显示库中的数据表:
usemysql;//打开库
showtables;
3、显示数据表的结构:
describe表名;
4、建库:
createdatabase库名;
5、建表:
use库名;
createtable表名(字段设定列表);
6、删库和删表:
dropdatabase库名;
droptable表名;
7、将表中记录清空:
deletefrom表名;
8、显示表中的记录:
selectfrom表名;
MySQL导入导出命令
1导出整个数据库
mysqlmp-u用户名-p数据库名>导出的文件名
mysqlmp-uwcnc-psmgp_apps_wcnc>wcncsql
2导出一个表
mysqlmp-u用户名-p数据库名表名>导出的文件名
mysqlmp-uwcnc-psmgp_apps_wcncusers>wcnc_userssql
3导出一个数据库结构
mysqlmp-uwcnc-p-d--add-drop-tablesmgp_apps_wcnc>d:wcnc_dbsql
-d没有数据--add-drop-table在每个create语句之前增加一个droptable
4导入数据库
常用source命令
进入mysql数据库控制台,如mysql-uroot-p
mysql>use数据库
然后使用source命令,后面参数为脚本文件(如这里用到的sql)
mysql>sourced:wcnc_dbsql(注:如果写成sourced:wcnc_dbsql,就会报语法错误
在开始演示之前,我们先介绍下两个概念。
概念一,数据的可选择性基数,也就是常说的cardinality值。
查询优化器在生成各种执行计划之前,得先从统计信息中取得相关数据,这样才能估算每步 *** 作所涉及到的记录数,而这个相关数据就是cardinality。简单来说,就是每个值在每个字段中的唯一值分布状态。
比如表t1有100行记录,其中一列为f1。f1中唯一值的个数可以是100个,也可以是1个,当然也可以是1到100之间的任何一个数字。这里唯一值越的多少,就是这个列的可选择基数。
那看到这里我们就明白了,为什么要在基数高的字段上建立索引,而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面,至于更深入的探讨就不在我这篇探讨的范围了。
概念二,关于HINT的使用。
这里我来说下HINT是什么,在什么时候用。
HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作,使她生成最优的执行计划。一般来说,优化器的执行计划都是最优化的,不过在某些特定场景下,执行计划可能不是最优化。
比如:表t1经过大量的频繁更新 *** 作,(UPDATE,DELETE,INSERT),cardinality已经很不准确了,这时候刚好执行了一条SQL,那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢?
来看下具体演示
譬如,以下两条SQL,
A:
select from t1 where f1 = 20;B:
select from t1 where f1 = 30;如果f1的值刚好频繁更新的值为30,并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等,那么对这两条语句来说,可能不准确的就是B了。
这里顺带说下,MySQL提供了自动更新和手动更新表cardinality值的方法,因篇幅有限,需要的可以查阅手册。
那回到正题上,MySQL 80 带来了几个HINT,我今天就举个index_merge的例子。
示例表结构:
mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+------------+--------------+------+-----+---------+----------------+| id | int(11) | NO | PRI | NULL | auto_increment || rank1 | int(11) | YES | MUL | NULL | || rank2 | int(11) | YES | MUL | NULL | || log_time | datetime | YES | MUL | NULL | || prefix_uid | varchar(100) | YES | | NULL | || desc1 | text | YES | | NULL | || rank3 | int(11) | YES | MUL | NULL | |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)表记录数:
mysql> select count() from t1;+----------+| count() |+----------+| 32768 |+----------+1 row in set (001 sec)这里我们两条经典的SQL:
SQL C:
select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;SQL D:
select from t1 where rank1 =100 and rank2 =100 and rank3 =100;表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。
那我们来看SQL C的查询计划。
显然,没有用到任何索引,扫描的行数为32034,cost为324365。
mysql> explain format=json select from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "324365" }, "table": { "table_name": "t1", "access_type": "ALL", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "rows_examined_per_scan": 32034, "rows_produced_per_join": 115, "filtered": "036", "cost_info": { "read_cost": "323207", "eval_cost": "1158", "prefix_cost": "324365", "data_read_per_join": "49K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))" } }}1 row in set, 1 warning (000 sec)我们加上hint给相同的查询,再次看看查询计划。
这个时候用到了index_merge,union了三个列。扫描的行数为1103,cost为44109,明显比之前的快了好几倍。
mysql> explain format=json select /+ index_merge(t1) / from t1 where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "44109" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "union(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1103, "rows_produced_per_join": 1103, "filtered": "10000", "cost_info": { "read_cost": "33079", "eval_cost": "11030", "prefix_cost": "44109", "data_read_per_join": "473K" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))" } }}1 row in set, 1 warning (000 sec)我们再看下SQL D的计划:
不加HINT,
mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "53434" }, "table": { "table_name": "t1", "access_type": "ref", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "idx_rank1", "used_key_parts": [ "rank1" ], "key_length": "5", "ref": [ "const" ], "rows_examined_per_scan": 555, "rows_produced_per_join": 0, "filtered": "007", "cost_info": { "read_cost": "47884", "eval_cost": "004", "prefix_cost": "53434", "data_read_per_join": "176" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))" } }}1 row in set, 1 warning (000 sec)加了HINT,
mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: { "query_block": { "select_id": 1, "cost_info": { "query_cost": "523" }, "table": { "table_name": "t1", "access_type": "index_merge", "possible_keys": [ "idx_rank1", "idx_rank2", "idx_rank3" ], "key": "intersect(idx_rank1,idx_rank2,idx_rank3)", "key_length": "5,5,5", "rows_examined_per_scan": 1, "rows_produced_per_join": 1, "filtered": "10000", "cost_info": { "read_cost": "513", "eval_cost": "010", "prefix_cost": "523", "data_read_per_join": "440" }, "used_columns": [ "id", "rank1", "rank2", "log_time", "prefix_uid", "desc1", "rank3" ], "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))" } }}1 row in set, 1 warning (000 sec)对比下以上两个,加了HINT的比不加HINT的cost小了100倍。
总结下,就是说表的cardinality值影响这张的查询计划,如果这个值没有正常更新的话,就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。
数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷
1 优化一览图
2 优化
笔者将优化分为了两大类,软优化和硬优化,软优化一般是 *** 作数据库即可,而硬优化则是 *** 作服务器硬件及参数设置
21 软优化
211 查询语句优化
1首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息
2例:
显示:
其中会显示索引和查询数据读取数据条数等信息
212 优化子查询
在MySQL中,尽量使用JOIN来代替子查询因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高
213 使用索引
索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:
214 分解表
对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,
215 中间表
对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时
216 增加冗余字段
类似于创建中间表,增加冗余也是为了减少连接查询
217 分析表,,检查表,优化表
分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费
1 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;
2 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]
option 只对MyISAM有效,共五个参数值:
3 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁
22 硬优化
221 硬件三件套
1配置多核心和频率高的cpu,多核心可以执行多个线程
2配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度
3配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行 *** 作的能力
222 优化数据库参数
优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能MySQL服务的配置参数都在mycnf或myini,下面列出性能影响较大的几个参数
223 分库分表
因为数据库压力过大,首先一个问题就是高峰期系统性能可能会降低,因为数据库负载过高对性能会有影响。另外一个,压力过大把你的数据库给搞挂了怎么办?所以此时你必须得对系统做分库分表 + 读写分离,也就是把一个库拆分为多个库,部署在多个数据库服务上,这时作为主库承载写入请求。然后每个主库都挂载至少一个从库,由从库来承载读请求。
224 缓存集群
如果用户量越来越大,此时你可以不停的加机器,比如说系统层面不停加机器,就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高,就扩容加数据库服务器,通过分库分表是可以支持扩容机器的,如果数据库层面的读并发越来越高,就扩容加更多的从库。但是这里有一个很大的问题:数据库其实本身不是用来承载高并发请求的,所以通常来说,数据库单机每秒承载的并发就在几千的数量级,而且数据库使用的机器都是比较高配置,比较昂贵的机器,成本很高。如果你就是简单的不停的加机器,其实是不对的。所以在高并发架构里通常都有缓存这个环节,缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万,甚至每秒数十万,对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性,对那种写少读多的请求,引入缓存集群。具体来说,就是在写数据库的时候同时写一份数据到缓存集群里,然后用缓存集群来承载大部分的读请求。这样的话,通过缓存集群,就可以用更少的机器资源承载更高的并发。
一个完整而复杂的高并发系统架构中,一定会包含:各种复杂的自研基础架构系统。各种精妙的架构设计因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了
以上就是关于在本地电脑MySQL中怎么创建数据库(如何搭建mysql数据库)全部的内容,包括:在本地电脑MySQL中怎么创建数据库(如何搭建mysql数据库)、面试中常问:mysql数据库做哪些优化也提高mysql性能、超详细MySQL数据库优化等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)