MySQL数据库开发的36条原则
欢迎添加华为云小助手微信(微信号:HWCloud002 或 HWCloud003),验证通过后,输入关键字“加群”,加入华为云线上技术讨论群;输入关键字“最新活动”,获取华为云最新特惠促销。华为云诸多技术大咖、特惠活动等你来撩!
前言
这些原则都是经历过实战总结而成
每一条原则背后都是血淋淋的教训
这些原则主要是针对数据库开发人员,在开发过程中务必注意
总是在灾难发生后,才想起容灾的重要性;
总是在吃过亏以后,才记得曾有人提醒过。
一、核心原则
1.尽量不在数据库做运算
俗话说:别让脚趾头想事情,那是脑瓜子的职责
作为数据库开发人员,我们应该让数据库多做她所擅长的事情:
尽量不在数据库做运算
复杂运算移到程序端CPU
尽可能简单应用MYSQL
举例:
在mysql中尽量不要使用如:md5()、Order by Rand()等这类运算函数
2.尽量控制单表数据量
大家都知道单表数据量过大后会影响数据查询效率,严重情况下会导致整个库都卡住
一般情况下,按照一年内单表数据量预估:
纯INT不超过1000W
含CHAR不超过500W
同时要尽量做好合理的分表,使单表数据量不超载,常见的分表策略有:
通过USERID来分表(根据ID区间分表):在金融行业应用较多,用户量大、用户特征明显
按DATE分表(按天、周、月分表):在电信行业应用非常多,如用户上网记录表、用户短信表、话单表等
按AREA分表(省、市、区分表)
其他
分区表的适用场景主要有:
① 表非常大,无法全部存在内存,或者只在表的最后有热点数据,其他都是历史数据;
② 分区表的数据更易维护,可以对独立的分区进行独立的操作;
③ 分区表的数据可以分布在不同的机器上,从而高效使用资源;
④ 可以使用分区表来避免某些特殊的瓶颈;
⑤ 可以备份和恢复独立的分区。
但是使用分区表同样有一些限制,在使用的时候需要注意:
① 一个表最多只能有 1024 个分区;
② 5.1版本中,分区表表达式必须是整数, 5.5可以使用列分区;
③ 分区字段中如果有主键和唯一索引列,那么主键列和唯一列都必须包含进来;
④ 分区表中无法使用外键约束;
⑤ 需要对现有表的结构进行修改;
⑥ 所有分区都必须使用相同的存储引擎;
⑦ 分区函数中可以使用的函数和表达式会有一些限制;
⑧ 某些存储引擎不支持分区;
⑨ 对于 MyISAM 的分区表,不能使用 load index into cache;
⑩ 对于 MyISAM 表,使用分区表时需要打开更多的文件描述符。
3.尽量控制表字段数量
单表的字段数量也不能太多,根据业务场景进行优化调整,尽量调整表字段数少而精,这样有以下好处:
IO高效
全表遍历
表修复快
提高并发
alter table更快
那究竟单表多少字段合适呢?
按照单表1G体积,500W行数据量进行评估:
顺序读1G文件需N秒
单行不超过200Byte
单表不超50个纯INT字段
单表不超20个CHAR(10)字段
==>建议单表字段数上限控制在20~50个
4.平衡范式与冗余
数据库表结构的设计也讲究平衡,以往我们经常说要严格遵循三大范式,所以先来说说什么是范式:
第一范式:单个字段不可再分。唯一性。
第二范式:不存在非主属性只依赖部分主键。消除不完全依赖。
第三范式:消除传递依赖。
用一句话来总结范式和冗余:
冗余是以存储换取性能,
范式是以性能换取存储。
所以,一般在实际工作中冗余更受欢迎一些。
模型设计时,这两方面的具体的权衡,首先要以企业提供的计算能力和存储资源为基础。
其次,一般互联网行业中都根据Kimball模式实施数据仓库,建模也是以任务驱动的,因此冗余和范式的权衡符合任务需要。
例如,一份指标数据,必须在早上8点之前处理完成,但计算的时间窗口又很小,要尽可能减少指标的计算耗时,这时在计算过程中要尽可能减少多表关联,模型设计时需要做更多的冗余。
5.拒绝3B
数据库的并发就像城市交通,呈非线性增长
这就要求我们在做数据库开发的时候一定要注意高并发下的瓶颈,防止因高并发造成数据库瘫痪。
这里的拒绝3B是指:
大SQL(BIG SQL):要减少
大事务(BIG Transaction)
大批量(BIG Batch)
二、字段类原则
1.用好数值字段类型
三类数值类型:
整型:TINYINT(1Byte)、TINYINT(1Byte)、SMALLINT(2B)、MEDIUMINT(3B)、INT(4B)、BIGINT(8B)
浮点型:FLOAT(4B)、DOUBLE(8B)
DECIMAL(M,D)
以几个常见的例子来进行说明:
1)INT(1) VS INT(11)
很多人都分不清INT(1)和INT(11)的区别,想必大家也很好奇吧,其实1和11其实只是显示长度的却别而已,也就是不管int(x)x的值是什么值,存储数字的取值范围还是int本身数据类型的取值范围,x只是数据显示的长度而已。
2)BIGINT AUTO_INCREMENT
大家都知道,有符号int最大可以支持到约22亿,远远大于我们的需求和MySQL单表所能支持的性能上限。对于OLTP应用来说,单表的规模一般要保持在千万级别,不会达到22亿上限。如果要加大预留量,可以把主键改为改为无符号int,上限为42亿,这个预留量已经是非常的充足了。
使用bigint,会占用更大的磁盘和内存空间,内存空间毕竟有限,无效的占用会导致更多的数据换入换出,额外增加了IO的压力,对性能是不利的。
因此推荐自增主键使用int unsigned类型,但不建议使用bigint。
3)DECIMAL(N,0)
当采用DECIMAL数据类型的时候,一般小数位数不会是0,如果小数位数设置为0,那建议使用INT类型
2.将字符转化为数字
数字型VS字符串型索引有更多优势:
更高效
查询更快
占用空间更小
举例:用无符号INT存储IP,而非CHAR(15)
INT UNSIGNED
可以用INET_ATON()和INET_NTOA()来实现IP字符串和数值之间的转换
3.优先使用ENUM或SET
对于一些枚举型数据,我们推荐优先使用ENUM或SET,这样的场景适合:
1)字符串型
2)可能值已知且有限
存储方面:
1)ENUM占用1字节,转为数值运算
2)SET视节点定,最多占用8字节
3)比较时需要加‘单引号(即使是数值)
举例:
`sex` enum('F','M') COMMENT '性别';
`c1` enum('0','1','2','3') COMMENT '审核';
4.避免使用NULL字段
为什么在数据库表字段设计的时候尽量都加上NOT NULL DEFAULT '',这里面不得不说用NULL字段的弊端:
很难进行查询优化
NULL列加索引,需要额外空间
含NULL复合索引无效
举例:
1)`a` char(32) DEFAULT NULL 【不推荐】
2)`b` int(10) NOT NULL 【不推荐】
3)`c` int(10) NOT NULL DEFAULT 0 【推荐】
5.少用并拆分TEXT/BLOB
TEXT类型处理性能远低于VARCHAR
强制生成硬盘临时表
浪费更多空间
VARCHAR(65535)==>64K(注意UTF-8)
尽量不用TEXT/BLOB数据类型
如果业务需要必须用,建议拆分到单独的表
举例:
CREATE TABLE t1 (
id INT NOT NULL AUTO_INCREMENT,
data TEXT NOT NULL,
PRIMARY KEY(id)
) ENGINE=InnoDB;
6.不在数据库里存图片
先上图:
可见,如果将图片全部存在数据库,将使得数据库体积变大,会造成读写速度变慢。
图片存数据库的弊端:
对数据库的读/写的速度永远都赶不上文件系统处理的速度
数据库备份变的巨大,越来越耗时间
对文件的访问需要穿越你的应用层和数据库层
★推荐处理办法:数据库中保存图片路径
按照年月日生成路径。具体是按照年月日还是按照年月去生成路径,根据自己需要(不一定是按照日期去生成)。
理解为什么要分散到多个文件夹中去才是关键,涉及到一个原理就明白了:
操作系统对单个目录的文件数量是有限制的。当文件数量很多的时候。从目录中获取文件的速度就会越来越慢。所以为了保持速度,才要按照固定规则去分散到多个目录中去。
图片分散到磁盘路径中去。数据库字段中保存的是类似于这样子的”images/2012/09/25/ 1343287394783.jpg”
原来上传的图片文件名称会重新命名保存,比如按照时间戳来生成,1343287394783. jpg。这样子是为了避免文件名重复,多个人往同一个目录上传图片的时候会出现。
反正用什么样的规则命名图片,只要做到图片名称的唯一性即可。
比如网站的并发访问量大,目录的生成分得月细越好。比如精确到小时,一个小时都可以是一个文件夹。同时0.001秒有两个用户同时在上传图片(因为那么就会往同一个小时文件夹里面存图片)。因为时间戳是精确到秒的。为了做到图片名称唯一性而不至于覆盖,生成可以在在时间戳后面继续加毫秒微秒等。总结的规律是,并发访问量越大。就越精确就好了。
题外话:
1)为什么保存的磁盘路径,是”images/2012/09/25/1343287394783.jpg”,而不是” /images/2012/09/25/ 1343287394783.jpg”(最前面带有斜杠)
在页面中需要取出图片路径展示图片的时候,如果是相对路径,则可以使用”./”+”images/2012/09/25/1343287394783.jpg”进行组装。
如果需要单独的域名(比如做cdn加速的时候)域名,img1.xxx.com,img2.xxx.com这样的域名,
直接组装 “http://img1.xxx.com/”+”images/2012/09/25/1343287394783.jpg”
2)为什么保存的磁盘路径,是”images/2012/09/25/1343287394783.jpg”,而不是“http://www.xxx.com/images/2012/09/25/1343287394783.jpg"
这里其实涉及到CDN的知识,具体CDN的知识在此不多展开,简而言之:
cdn服务:对于静态内容是非常适合的。所以像商品图片,随着访问量大了后,租用cdn服务,只需要把图片上传到他们的服务器上去。
例子:北京访问长沙服务器,距离太远。我完全可以把商品图片,放到北京的云服务(我觉得现在提供给网站使用的云存储其实就是cdn,给网站提供分流和就近访问)上去。这样子北京用户访问的时候,实际上图片就是就近获取。不需要很长距离的传输。
自己用一个域名img.xxx.com来载入图片。这个域名解析到北京的云服务上去。
做法:数据库中保存的是” images/2012/09/25/1343287394783.jpg”,
这些图片实际上不存储在web服务器上。上传到北京的cdn服务器上去。
我从数据库取出来,直接”img.xxx.com/”+” images/2012/09/25/1343287394783.jpg”
比如如果还有多个,就命名img1.xx.com、img2.xx.com
反正可以随便。所以如果把域名直接保存进去。就显得很麻烦了。迁移麻烦。
三、索引类原则
1.谨慎合理添加索引
添加索引是为了改善查询
添加索引会减慢更新
索引不是越多越好
能不加的索引尽量不加(综合评估数据密度和数据分布,最好不超过字段数20%)
结合核心SQL有限考虑覆盖索引
举例:不要给“性别”列创建索引
理论文章会告诉你值重复率高的字段不适合建索引。不要说性别字段只有两个值,网友亲测,一个字段使用拼音首字母做值,共有26种可能,加上索引后,百万加的数据量,使用索引的速度比不使用索引要慢!
为什么性别不适合建索引呢?因为你访问索引需要付出额外的IO开销,你从索引中拿到的只是地址,要想真正访问到数据还是要对表进行一次IO。假如你要从表的100万行数据中取几个数据,那么利用索引迅速定位,访问索引的这IO开销就非常值了。但如果你是从100万行数据中取50万行数据,就比如性别字段,那你相对需要访问50万次索引,再访问50万次表,加起来的开销并不会比直接对表进行一次完整扫描小。
2.字符字段必须建前缀索引
区分度:
单字母区分度:26
4字母区分度:26*26*26*26 = 456,976
5字母区分度:26*26*26*26*26 = 11,881,376
6字母区分度:26*26*26*26*26*26 = 308,915,776
字符字段必须建前缀索引,例如:
`pinyin` varchar(100) DEFAULT NULL COMMENT '小区拼音',
KEY `idx_pinyin` (`pinyin`(8)),
) ENGINE=InnoDB
3.不在索引列做运算
原因有两点:
1)会导致无法使用索引
2)会导致全表扫描
举例:
BAD SAMPLE:
select * from table
WHERE to_days(current_date) – to_days(date_col) <= 10
GOOD SAMPLE:
select * from table
WHERE date_col >= DATE_SUB('2011-10-22',INTERVAL 10 DAY);
4.自增列或全局ID做INNODB主键
对主键建立聚簇索引
二级索引存储主键值
主键不应更新修改
按自增顺序插入值
忌用字符串做主键
聚簇索引分裂
推荐用独立于业务的AUTO_INCREMENT列或全局ID生成器做代理主键
若不指定主键,InnoDB会用唯一且非空值索引代替
5.尽量不用外键
线上OLTP系统尽量不用外键:
外键可节省开发量
有额外开销
逐行操作
可“到达”其他表,意味着锁
高并发时容易死锁
建议由程序保证约束
比如我们原来建表语句是这样的:
CREATE TABLE `user` (
`user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`user_name` varchar(50) NOT NULL DEFAULT '' COMMENT '用户名',
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `order` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`total_price` decimal(10,2) NOT NULL DEFAULT '0.00',
`user_id` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `for_indx_user_id` (`user_id`),
CONSTRAINT `for_indx_user_id` FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
不使用外键约束后:
CREATE TABLE `user` (
`user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`user_name` varchar(50) NOT NULL DEFAULT '' COMMENT '用户名',
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `order` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`total_price` decimal(10,2) NOT NULL DEFAULT '0.00',
`user_id` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
不适用外键约束后,为了加快查询我们通常会给不建立外键约束的字段添加一个索引。
CREATE TABLE `order` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
`total_price` decimal(10,2) NOT NULL DEFAULT '0.00',
`user_id` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
实际开发中,一般不会建立外键约束。
四、SQL类原则
1.SQL语句尽可能简单
在开发过程中,我们尽量要保持SQL语句的简单性,我们对比一下大SQL和多个简单SQL
传统设计思想
BUG MySQL NOT
一条SQL只能在一个CPU运算
5000+ QPS的高并发中,1秒大SQL意味着?
可能一条大SQL就把整个数据库堵死
拒绝大SQL,拆解成多条简单SQL
简单SQL缓存命中率更高
减少锁表时间,特别是MyISAM
用上多CPU
2.保持事务(连接)短小
事务/连接使用原则:即开即用,用完即关
与事务无关操作都放到事务外面,减少锁资源的占用
不破坏一致性前提下,使用多个短事务代替长事务
举例:
1)发帖时的图片上传等待
2)大量的sleep连接
3.尽可能避免使用SP/TRIG/FUNC
线上OLTP系统中,我们应当:
尽可能少用存储过程
尽可能少用触发器
减少使用MySQL函数对结果进行处理
将上述这些事情都交给客户端程序负责
4.尽量不用SELECT *
用SELECT * 时,将会更多的消耗CPU、内存、IO以及网络带宽
我们在写查询语句时,应当尽量不用SELECT * ,只取需要的数据列:
更安全的设计:减少表变化带来的影响
为使用covering index提供可能性
Select/JOIN 减少硬盘临时表生成,特别是有TEXT/BLOB时
举例:
不推荐:
SELECT * FROM tag
WHERE id = 999148
推荐:
SELECT keyword FROM tag
WHERE id = 999148
5.改写OR为IN()
同一字段,将or改写为in()
OR效率:O(n)
IN效率:O(Log n)
当n很大时,OR会慢很多
注意控制IN的个数,建议n小于200
举例:
不推荐:
Select * from opp WHERE phone='12347856' or phone='42242233'
推荐:
Select * from opp WHERE phone in ('12347856' , '42242233')
6.改写OR为UNION
不同字段,将or改为union
减少对不同字段进行 "or" 查询
Merge index往往很弱智
如果有足够信心:set global optimizer_switch='index_merge=off';
举例:
不推荐:
Select * from opp
WHERE phone='010-88886666'
or
cellPhone='13800138000';
推荐:
Select * from opp
WHERE phone='010-88886666'
union
Select * from opp
WHERE cellPhone='13800138000';
7.避免负向查询和%前缀模糊查询
在实际开发中,我们要尽量避免负向查询,那什么是负向查询呢,主要有以下:
NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等
同时,我们还要避免%前缀模糊查询,因为这样会使用B+ Tree,同时会造成使用不了索引,并且会导致全表扫描,性能和效率可想而知
举例:
8.减少COUNT(*)
在开发中我们经常会使用COUNT(*),殊不知这种用法会造成大量的资源浪费,因为COUNT(*)资源开销大,所以我们能不用尽量少用
对于计数类统计,我们推荐:
实时统计:用memcache,双向更新,凌晨跑基准
非实时统计:尽量用单独统计表,定期重算
来对比一下COUNT(*)和其他几个COUNT吧:
`id` int(10) NOT NULL AUTO_INCREMENT COMMENT '公司的id',
`sale_id` int(10) unsigned DEFAULT NULL,
结论:
COUNT(*)=COUNT(1)
COUNT(0)=COUNT(1)
COUNT(1)=COUNT(100)
COUNT(*)!=COUNT(col)
9.LIMIT高效分页
传统分页:
Select * from table limit 10000,10;
LIMIT原理:
Limit 10000,10
偏移量越大则越慢
推荐分页:
Select * from table WHERE id>=23423 limit 11;
#10+1 (每页10条)
select * from table WHERE id>=23434 limit 11;
分页方式二:
Select * from table WHERE id >= ( select id from table limit 10000,1 ) limit 10;
分页方式三:
SELECT * FROM table INNER JOIN (SELECT id FROM table LIMIT 10000,10) USING (id) ;
分页方式四:
#先使用程序获取ID:
select id from table limit 10000,10;
#再用in获取ID对应的记录
Select * from table WHERE id in (123,456…) ;
具体需要根据实际的场景分析并重组索引
示例:
10.用UNION ALL 而非UNION
如果无需对结果进行去重,仅仅是对多表进行联合查询并展示,则用UNION ALL,因为UNION有去重开销
举例:
MySQL>SELECT * FROM detail20091128 UNION ALL
SELECT * FROM detail20110427 UNION ALL
SELECT * FROM detail20110426 UNION ALL
SELECT * FROM detail20110425 UNION ALL
SELECT * FROM detail20110424 UNION ALL
SELECT * FROM detail20110423;
11.分解联接保证高并发
高并发DB不建议进行两个表以上的JOIN
适当分解联接保证高并发:
可缓存大量早期数据
使用了多个MyISAM表
对大表的小ID IN()
联接引用同一个表多次
举例:
原SQL:
MySQL> Select * from tag
JOIN tag_post
on tag_post.tag_id=tag.id
JOIN post
on tag_post.post_id=post.id
WHERE tag.tag=‘二手玩具’;
分解SQL:
MySQL> Select * from tag WHERE tag=‘二手玩具’;
MySQL> Select * from tag_post WHERE tag_id=1321;
MySQL> Select * from post WHERE post.id in (123,456,314,141)
12.GROUP BY 去除排序
使用GROUP BY可以实现分组和自动排序
无需排序:Order by NULL
特定排序:Group by DESC/ASC
举例:
13.同数据类型的列值比较
原则:数字对数字,字符对字符
数值列与字符类型比较:同时转换为双精度进行比对
字符列与数值类型比较:字符列整列转数值,不会使用索引查询
举例:
字段:`remark` varchar(50) NOT NULL COMMENT '备注,默认为空',
MySQL>SELECT `id`, `gift_code` FROM gift
WHERE `deal_id` = 640 AND remark=115127;
1 row in set (0.14 sec)
MySQL>SELECT `id`, `gift_code` FROM pool_gift
WHERE `deal_id` = 640 AND remark='115127';
1 row in set (0.005 sec)
14.Load data 导数据
批量数据快导入:
成批装载比单行装载更快,不需要每次刷新缓存
无索引时装载比索引装载更快
Insert values ,values,values 减少索引刷新
Load data比insert快约20倍
尽量不用INSERT ... SELECT,一个是有延迟,另外就是会同步出错
15.打散大批量更新
大批量更新尽量凌晨操作,避开高峰
凌晨不限制
白天上线默认为100条/秒(特殊再议)
举例:
update post set tag=1 WHERE id in (1,2,3);
sleep 0.01;
update post set tag=1 WHERE id in (4,5,6);
sleep 0.01;
……
16.Know Every SQL
作为DBA乃至数据库开发人员,我们必须对数据库的每条SQL都非常了解,常见的命令有:
SHOW PROFILE
MYSQLsla
MySQLdumpslow
explain
Show Slow Log
Show Processlist
SHOW QUERY_RESPONSE_TIME(Percona)
五、约定类原则
1.隔离线上线下
构建数据库的生态环境,确保开发无线上库操作权限
原则:线上连线上,线下连线下
生产数据用pro库
预生产环境用pre库
测试用test库
开发用dev库
2.禁止未经DBA确认的子查询
大部分情况优化较差
特别WHERE中使用IN id的子查询
一般可用JOIN改写
举例:
MySQL> select * from table1 where id in (select id from table2);
MySQL> insert into table1 (select * from table2); //可能导致复制异常
3.永远不在程序端显式加锁
外部锁对数据库丌可控
高幵发时是灾难
极难调试和排查
对于类似并发扣款等一致性问题,我们采用事务来处理,Commit前进行二次校验冲突
4.统一字符集为UTF8
5.统一命名规范
1)库表等名称统一用小写
2)索引命名默认为“idx_字段名"
3)库名用缩写,尽量在2~7个字母
DataSharing ==> ds
4)注意避免用保留字命名
以上所有坑,建议数据库开发人员都要铭记于心。
作者:真爱无敌
欢迎添加华为云小助手微信(微信号:HWCloud002 或 HWCloud003),验证通过后,输入关键字“加群”,加入华为云线上技术讨论群;输入关键字“最新活动”,获取华为云最新特惠促销。华为云诸多技术大咖、特惠活动等你来撩!
MySQL数据库开发的36条原则的更多相关文章
- MySQL数据库开发的36条原则【华为云技术分享】
版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/devcloud/article/detai ...
- MySQL 数据库开发的 36 条军规
MySQL 数据库开发的 36 条军规 写在前面的话: 总是在灾难发生后,才想起容灾的重要性: 总是在吃过亏后,才记得曾经有人提醒过. (一)核心军规 (1)不在数据库做运算:cpu计算务必移至业务层 ...
- MySQL数据库开发规范-EC
最近一段时间一边在线上抓取SQL来优化,一边在整理这个开发规范,尽量减少新的问题SQL进入生产库.今天也是对公司的开发做了一次培训,PPT就不放上来了,里面有十来个生产SQL的案例.因为规范大部分还是 ...
- PHP+mysql数据库开发搜索功能:中英文分词+全文检索(MySQL全文检索+中文分词(SCWS))
PHP+mysql数据库开发类似百度的搜索功能:中英文分词+全文检索 中文分词: a) robbe PHP中文分词扩展: http://www.boyunjian.com/v/softd/robb ...
- 原生Jdbc操作Mysql数据库开发步骤
原生Jdbc操作Mysql数据库开发步骤 原生的Jdbc就是指,不使用任何框架,仅用java.sql包下的方法实现数据库查询等的操作. 下面是开发步骤: 1.导入数据库驱动包 ...
- 第四模块:网络编程进阶&数据库开发 第2章·MySQL数据库开发
01-MySQL开篇 02-MySQL简单介绍 03-不同平台下安装MySQL 04-Windows平台MySQL密码设置与破解 05-Linux平台MySQL密码设置与破解 06-Mac平台MySQ ...
- MySQL数据库开发规范知识点
前言: 设计规范更多的是为了确保数据库设计的合理性.为了项目最终的协调稳定性,而命名规范则更多的是为了确保设计的正式和统一. 约定优先于配置(Convention Over Configuration ...
- mysql数据库开发常见问题及优化
mysql 数据库是被广泛应用的关系型数据库,其体积小.支持多处理器.开源并免费的特性使其在 Internet 中小型网站中的使用率尤其高.在使用 mysql 的过程中不规范的 SQL 编写.非最优的 ...
- 微渠道发展 BAE交通运输平台和java呼声,微信mysql数据库开发实例 --图文开发教程
持续更新 BAE java开展mysql数据库 图文教程 BAE java语言发展mysql源码下载: 目前微信的发展.BAE开展.java开展.mysql教程开发非常,的介绍基于BAE平台.java ...
随机推荐
- CSPS模拟 73
被T3坑了 忘记考虑$atan$只会返回正数导致无法区分方向相反模长相等的两个向量 直接把向量拆成ab两个上三角函数干出来就对了 真的exhausted
- 基于canvas的流程编辑器
今年由于项目上需要给客户的流程管理系统进行升级,其中包含流程的可视化.于是在网上找一些可以用的轮子,考察了D3,js.GooFlow.js.G6-Editor等工具后,发现D3,js学习成本太高,G6 ...
- vmware centos共享文件夹
vmware centos共享文件夹 查看VMware Tools 是否安装成功 <pre>vmware-hgfsclient</pre> 出现共享文件夹<pre> ...
- 在Debian/Ubuntu上面安装升级nginx到最新版
在Debian下面通过 apt-get 可以自动安装 nginx,不过版本一般比较老,如果想要使用nginx的最新特性就需要升级版本. 一般安装可以通过编绎源文件安装,但可能需要安装很多编绎工具, ...
- 花了几个小时总结了一些容易出错的 Java 知识点!
本文已经收录自 JavaGuide (61k+Star![Java学习+面试指南] 一份涵盖大部分Java程序员所需要掌握的核心知识.欢迎 Star!欢迎骚扰!) 原文地址:https://javag ...
- window,sts安装python
1.先在python官网下载最新的python安装,安装的时候勾上所有选项 官网:https://www.python.org/downloads/ 2.在sts里安装pyDev插件,我当时直接sea ...
- idea2017建立jsp工程及tomcat等配置
1:建立工程,选择Java Enterprise,可能需要选择tomcat路径和jdk路径: =============================== 以下作为第二种方式参考: 1:创建新工程 ...
- django_2:模板
使用模板变量: 在html文件中,{{title}}即为模板变量, 在view.py文件中,render函数,增加第三个参数,以字典形式给值. def index(req): return rende ...
- MAC终端中tree命令
Mac没有自带的tree命令,需要额外安装才可以,操作方法有两种: 一.用find命令模拟tree效果 1.mac下默认是没有 tree命令的,不过我们可以使用find命令模拟出tree命令的效果,如 ...
- 从零开始在ubuntu上配置深度学习开发环境
从零开始在ubuntu上配置深度学习开发环境 昨天一不小心把原来配置好的台式机的开发环境破坏了,调了半天没有调回来,索性就重装一次ubuntu系统.这篇文章主要记录一个简单的.‘傻瓜式’教程. 一.U ...