安装完 MySQL 后,要修改密码. step 1: SET PASSWORD = PASSWORD('your new password'); step 2: ALTER USER 'root'@'localhost' PASSWORD EXPIRE NEVER; step 3: flush privileges; 接下来要建立一个支持中文的数据库. create database gotopaste default character set utf8mb4 collate utf8mb4_

mysql workbench 建表时 - PK: primary key (column is part of a pk) 主键 - NN: not null (column is nullable) 非空 - UQ: unique (column is part of a unique key) 唯一 - AI: auto increment (the column is auto incremented when rows are inserted) 自增 - BIN: binary (i

1.符合数据库三范式 2.字段选择合适的数据类型 3.注意表之间的联系,一对多,多对多,一对一 4.拆分表,把不常用的字段单独成表. 5.建立索引,哪些字段建立索引?建立索引的原则?最左前缀原则,where子句原则 mysql优化包括: 1.选择合适的存储引擎 2.合适的建表 3.sql语句的书写,哪些语句会用上索引. 4.数据库读写分离,一个master负责写,slave负责读.利用bin log采用日志同步. 5.表的垂直划分和水平划分.

一.CREATE TABLE 选项 1.在定义列的时候,指定列选项 1)DEFAULT <literal>:定义列的默认值 当插入一个新行到表中并且没有给该列明确赋值时,如果定义了列的默认值,将自动得到默认值 :如果没有,则为null. mysql> create table people -> ( -> id int not null primary key, -> name varchar() not null, -> sex ) default 'm' -&

200 ? "200px" : this.width)!important;} --> 介绍 mysql分区后每个分区成了独立的文件,虽然从逻辑上还是一张表其实已经分成了多张独立的表,从“information_schema.INNODB_SYS_TABLES”系统表可以看到每个分区都存在独立的TABLE_ID,由于Innodb数据和索引都是保存在".ibd"文件当中(从INNODB_SYS_INDEXES系统表中也可以得到每个索引都是对应各自的分区(prim

1.创建表的时候必须指定主键,并且主键建立后最好不要再有数据修改的需求 mysql从5.5版本开始默认使用innodb引擎,innodb表是聚簇索引表,也就是说数据通过主键聚集( 主键下存储该行的数据,索引指向主键值),如下图所示: 正是由于这种解构,如果后续对主键对应的值进行修改,就会导致索引节点的频繁分裂,性能会下降非常厉害.因此推荐开发的同事们使用和业务没有任何关联的自增id来做主键(切记不要使用uuid来做主键),此外也可以考虑使用其他的方式来生产自增的ID,比如使用Twitter的sn

阅读目录---MySQL常见的建表选项及约束: 1.create table选项 1.指定列选项:default.comment 2.指定表选项:engine.auto_increment.comment 2.create table约束 1.not null:非空约束 2.unique:唯一约束 3.primary key:主键约束 4.foreign key:外键 5.check:检查---enum.set 一.CREATE TABLE 选项 1.在定义列的时候,指定列选项 1)DEFAUL

介绍 mysql分区后每个分区成了独立的文件,虽然从逻辑上还是一张表其实已经分成了多张独立的表,从“information_schema.INNODB_SYS_TABLES”系统表可以看到每个分区都存在独立的TABLE_ID,由于Innodb数据和索引都是保存在".ibd"文件当中(从INNODB_SYS_INDEXES系统表中也可以得到每个索引都是对应各自的分区(primary key和unique也不例外)),所以分区表的索引也是随着各个分区单独存储. 在INNODB_SYS_IN

更多内容推荐微信公众号,欢迎关注: 1 查看系统支持的存储引擎 show engines; 2 查看表使用的存储引擎 两种方法: a.show table status from db_name where name='table_name'; b.show create table table_name; 如果显示的格式不好看,可以用\g代替行尾分号 有人说用第二种方法不准确,我试了下,关闭掉原先默认的Innodb引擎后根本无法执行show create table table_name指令,

[1]建立员工档案表要求字段:员工员工编号,员工姓名,性别,工资,email,入职时间,部门.[2]合理选择数据类型及字段修饰符,要求有NOT NULL,auto_increment, primary key等. -- -- make by kakane -- DROP TABLE IF EXISTS `workers_info`; CREATE TABLE `workers_info` ( `id` int(11) NOT NULL AUTO_INCREMENT, `workername` v

最近项目中用到了使用存储过程批量建表的功能,记录下来: USE db_test_3; drop procedure if EXISTS `createTablesWithIndex`; create procedure createTablesWithIndex() BEGIN ); ); ); ); ); ; DO -- `M_ID` bigint AUTO_INCREMENT PRIMARY KEY NOT NULL, -- 创建表 SET @createSql = CONCAT('CREA

有两个表,表a CREATE TABLE `a` ( `id` mediumint() unsigned NOT NULL AUTO_INCREMENT, `fid` ) unsigned ', `cnt` ) unsigned ', ... ... ... PRIMARY KEY (`id`), KEY `idx_fid` (`fid`), ) ENGINE=MyISAM DEFAULT CHARSET=utf8 表b CREATE TABLE `b` (`fid` ) unsigned NO

1.库名.表名.字段名必须使用小写字母,“_”分割. 原因: MySQL在Linux下数据库名.表名.列名.别名大小写规则是这样的: 1.数据库名与表名是严格区分大小写的: 2.表的别名是严格区分大小写的: 3.列名与列的别名在所有的情况下均是忽略大小写的: 4.变量名也是严格区分大小写的:MySQL在Windows下都不区分大小写. 所以在不同操作系统中为了能使程序和数据库都能正常运行,最好的办法是在设计的时候都转为小写,但是如果在设计的时候已经规范化大小写了,那么在Windows环境下只要对

建立索引常用的规则如下: 1.表的主键.外键必须有索引: 2.数据量超过300的表应该有索引:3.经常与其他表进行连接的表,在连接字段上应该建立索引: 4.经常出现在Where子句中的字段,特别是大表的字段,应该建立索引:5.索引应该建在选择性高的字段上:6.索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引:7.复合索引的建立需要进行仔细分析:尽量考虑用单字段索引代替: A.正确选择复合索引中的主列字段,一般是选择性较好的字段: B.复合索引的几个字段是否经常同时以AND方式出现在

一. 表设计规范 库名.表名.字段名必须使用小写字母,“_”分割. 库名.表名.字段名必须不超过12个字符. 库名.表名.字段名见名知意,建议使用名词而不是动词. 建议使用InnoDB存储引擎. 存储精确浮点数必须使用DECIMAL替代FLOAT和DOUBLE. 建议使用UNSIGNED存储非负数值. 建议使用INT UNSIGNED存储IPV4. 整形定义中不添加长度,比如使用INT,而不是INT(4). 使用短数据类型,比如取值范围为0-80时,使用TINYINT UNSIGNED. 不建议

虽然一直都知道,类型 之类的字段 直接用字符窜会很方便,不过最好还是不要用字符串:但是也不是特别清楚为什么不要用,时间久了 就忍不住用一下字符窜试试,这一试 还挺好用的,吓得我 感觉探究了一下 为什么最好不要用字符窜. 一是从空间上考虑,对于类型 分类的字段来说,用int代表不同的类型,比varchar 更节省空间. 数据量少的时候 不明显,但是 数据量特别大,或者数据常加载到内存里 差别就比较明显了. 二是 从 安全性考虑,varchar 容错性高,会导致 程序的bug 不能那么及时的体现出来

1.create schema [数据库名称] default character set utf8 collate utf8_general_ci;--创建数据库 采用create schema和create database创建数据库的效果一样. 2.create user '[用户名称]'@'%' identified by '[用户密码]';--创建用户 密码8位以上,包括:大写字母.小写字母.数字.特殊字符 %:匹配所有主机,该地方还可以设置成‘localhost’,代表只能本地访问,

在微信公众号上看到一篇文章说的很好,意思是说,大牛在尝试各种方案的时候可能并没有超神的预测和筛选能力 只是你通常测试一种情况时,大神已经测试了好几种方案了,讲的是"为什么大多数程序员不喜欢写测试"的问题, 作者说,很多人觉得有些东西,谷歌百度一下随便都查得到,就像字典一样,没必要非要死记着,然后讲到 诸如快捷键的使用这些问题……讲了这么多,给笔者的感受,并没有那么简单,当你在查命令,找快捷键甚至按钮 的时候,那些大神们早已写完了测试用例并完成了测试... 这是闲话,以前我也爱写命令的手

本学期正在学习数据库,前段时间老师让我们做一下50个经典SQL语句,当时做的比较快,有一些也是百度的,自我感觉理解的不是很透彻. 所以从本篇随笔开始,我将进行50个经典SQL语句的复盘,加深理解. 答案仅供参考,不一定完全正确,若发现错误或有更好的,欢迎评论,互相交流,一起成长!!! --------------------------表结构-------------------------- student(StuId,StuName,StuAge,StuSex) 学生表 teacher(TI

场景描述: 项目采用了分库模式进行不同业务的开发,在共有的功能模块进行设计的时候采用主从库,或者各分库之中存在同样的库表结构,在使用过程中做库表同步的时候一定要保证库表所在的数据库的字符集和编码格式是保持一致的.否则完成库表同步或者迁移之后会造成查询问题:各独立库表查询数据都没有问题,但是在等值查询或者关联查询的时候会出现查询数据为空的现象:骚操作:在A库中把表建好了,copy到B库中,导致库表的排序规则不一致大小写匹配的时候出现问题. 逻辑描述: 在数据从app入库的时候存储的是大写的字符co

今天建了一张表,表名为--inOut: 然后再使用中发现怎么都是SQL错误: 然后在Navacat上发现 这是一个关键词! 如果非要继续使用,只能这样: 类似的坑还有user等.