web电商项目

一：web测试的目的：

web测试就是基于B/S框架的软件产品的测试，通俗点来说就是基于web网站的测试。

路线图：前期准备--需求评审---设计评审---测试计划---功能测试---环境搭建---测试用例---测试架构---性能测试--安全测试---兼容性测试---Bug测试总结

测试对象：禅道。

禅道需要解决痛点：

需求功能列表1

个人管理

使用待办进行个人事务管理

关注需要自己处理的任务、需求bug

通过我的档案查看或者修改个人信息

开发团队篇

参加项目计划会议、分解任务

领取任务，并每天更新任务

创建版本

申请测试

解决bug

文档管理

确认bug

产品经理篇

维护产品

创建和评审需求

变更和评审需求

需求的状态和研发阶段

需求的注意事项

维护产品模块

建立发布计划

建立发布

路线图

文档管理

主持产品会议

参与项目管理、演示、和总结

需求的基本统计报表

项目经理篇

建立项目

组建项目团队

确定项目要完成的需求列表

组织进行任务分解

召开每天的独立会议

通过燃尽图了解项目进展

通过各种列表的各种功能了解项目进展

召开演示会议和总结会议

项目任务的基本报表统计

测试团队篇

维护bug视图模块

提交bug

验证bug，bug关闭

激活bug

找到自己需要的bug

维护测试用例视图

创建测试用例

管理测试任务

执行用例，并提交bug

查看报表统计

评审过程：

项目经理确定评审组长

指定并发布评审计划

准备评审

改正、追踪、回归评审

归档

　　二、WEB功能测试包括哪些方面？

功能测试主要包括6大部分：

1、链接测试

2、表单测试

3、搜索测试

4、删除测试

5、cookies、session测试

6、数据库测试

1、链接测试

1）测试所有链接是否按照指示那样确实链接到了该链接的页面

2）测试所链接的页面是否存在

3）测试web应用系统上面有没有孤立的页面

2、表单测试

　　表单一般指在界面进行数据提交操作的，包括新增和修改数据。它涉及到的测试包括以下方面：

1）输入框测试

——长度、数据类型、必填、重复、空格、sql注入以及一些业务相关约束

2）下拉框测试

——默认值、数据完整性/正确性、第一个/最后一个/中间一个选取、手动输入值模糊匹配、联动选择；业务常见选取的操作

3）图片、视频、excel、txt等文件上传测试

——大小、尺寸、格式、数量、文件内容规则验证

4）表单提交按钮测试

——是否支持回车/单击、快速多次点击是否重复提交表单、网络中断（弱网）提交、提交后是否有提示、提交后内容是否加密、提交是否做权限校验控制、多人针对表单同时操作的场景测试。

3、搜索测试

　　搜索条件一般分为两种情况：输入框、下拉框。对于多个条件的页面搜索可以按照下面的编号顺序去进行测试：

1）任单个条件查询：模糊搜索、超长搜索、不存在与之匹配的条件、为空

2）任两个组合查询：确保任两个组合查询的正确性，验证两个组合的所有情况。

3）三个组合查询：不需要测试三个组合的全部级组合。因为前面针对所有单个条件的搜索、两个组合的所有组合进行测试了，那么在这里选择2-3组三种组合进行测试即可。

4）全条件组合查询：确保最大组合的正确性。

5）默认条件查询：补充默认条件查询的用例。

6）根据需求或者业务规则选取重点条件组合查询。

　　搜索框还有一种常见的情况就是：时间输入框

　　关于按照时间来搜索的测试点，可以从以下考虑：

1）开始时间<=结束时间，测试一个小时、夸时、当天、夸天、夸月、夸年的数据。

2）开始时间大于/小于当前时间，若是针对出生年月搜索，验证大于的情况；若是定时任务时间搜索验证小于的情况

3）只输入开始时间/结束时间

4）开始时间、结束时间都不输入

5）开始时间>结束时间

6）手动输入时间，注意时间格式验证

4、删除测试

1）没选择数据，点击删除　　——是否有友好提示

2）选择一条数据，点击删除　　——是否提示删除确认信息，需二次确认

3）删除一条数据后，点击添加　　——是否可以添加相同的数据

4）连续删除多个产品，选择批量删除　　——是否支持

5）删除一个有关联性的数据　　——（如删除QQ分组，组下好友会有提示）

6）所有删除数据操作，要注意相应查询页面及其关联界面的数据是否及时更新

5、cookies/session测试

cookies/session通常用来存储用户信息，cookies通过客户端记录信息确定用户身份，session通过在服务器端记录信息确定用户身份。

cookies/session测试同理，测试的内容可包括：

1）打开web系统后，在浏览器默认存储cookies的目录下看此cookies目录是否存在。

2）已知cookies的保存时间，测试时间范围之内和之外的cookies文件是否正常

3）将浏览器下的所有cookies文件删除。再次登录系统，会怎么处理。

6、数据库测试

　　在web应用技术中，数据库就是一个“仓库”，我们在进行功能测试的任何操作都可以归溯到对于数据库的增删查改。

　　所以，数据库测试实际就是通过前面讲的测试手段来完成，只不过关注点是数据库表及表字段值得变化。

1）、数据库脚本执行　　——数据库表添加、修改是否正常。

2）、页面提交表单、修改、查询、删除　　——数据库表信息是否正常

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

1.需求分析

2.快速熟悉项目

3.页面初始化测试

4.防御性代码测试

5.详细功能测试

5.1 数据分析

5.2 数据构造(举例)

5.2.1 前台注册页面输入框（等价类边界值法）

5.2.2 后台搜索用户页面输入框

5.2.3 前台搜索商品价格输入框

5.2.4 前台搜索商品品牌、价格选择字段（正交法）

5.2.5 其他需要注意的测试内容

5.2.5.1模态窗口

5.2.5.2 动画

5.2.5.3 banner图

5.3 编写测试用例

6.非功能测试

6.1 sql注入攻击

6.2 js注入攻击

6.3 fiddler抓包

7.根据需求文档，编写和执行流程、场景测试用例

8.查询数据库

9.Bug跟踪处理和回归测试

10.结束测试

电商项目

Windows下部署环境：前期准备--需求评审---设计评审---测试计划---功能测试---环境搭建---测试用例---测试架构---性能测试--安全

Windows下安装Wa mp环境

前台地址：http://localhost:8080/iwebshop/index.php?controller=site&action=index

后台地址：http://localhost:8080/iwebshop/index.php?controller=systemadmin&action=index

http://localhost:8080/iwebshop/ 因为改了端口号访问时加上端口号

项目安装：

这里需要说明一下连接本地的MySQL 有密码写上表前缀是iweb_ 不然后期连接非本地数据库无法测出数据

项目调研：

组织架构图：以思维导图的模式展示

后台模块：得出简单组织架构图

前后台测试范围列表：

测试计划：

测试用例模板

测试方案

对于小企业有可能测试计划和方案是一个东西

禅道管理文档

初始化页面测试

通过后台的工具---数据库备份的功能，核对数据库表是否对应再编写sql语句与页面进行对比

分析3：

热门搜索：

热门搜索关键词数据库：iwebshop_keyword找到对应的数据库表

修改数据内容观察和哪个变量有关写出对应的sql语句通过对其数据库的查看hot为1优先排序，选择hot为1的前五个数据：所以sql语句为： SELECT word from iweb_keyword WHERE hot=1 ORDER BY `order` LIMIT 5;

全部商品分类：

商品分类表：iweb_category

观察表变量关系尝试最终得出sql语句为：

SELECT `name` from iweb_category WHERE parent_id=0 ORDER BY sort;

虽然查出的数据是对的但考虑不完全显示五个数据

SELECT name from iweb_category WHERE parent_id=0 and visibility=1 ORDER BY sort LIMIT 5;

商品分类----服饰鞋帽的一级分类：

SELECT * FROM iweb_category WHERE parent_id =57 and visibility =1 ORDER BY id

Shop资讯：

SELECT title FROM iweb_article where visiblity AND top =1 ORDER BY create_time desc

最新商品：这是 iweb_commend_goods表和iweb_goods 表联合查出来的

这里涉及到左右连接及全连接、内连接的知识点，

【总结：
左连接where只影响右表，右连接where只影响左表

左连接后的检索结果是显示左表的所有数据和右表中满足where条件的数据。

右连接的检索结果是显示右表的所有数据和左表中没满足where条件的数据。

inner join，“有效连接”，两张表中都有的数据才会显示。

外连接有三种类型：完全外联，左联，右联

一般要使得数据库查询语句性能好点，遵循以下原则

在做表与表的连接查询时，大表在前，小表在后

不使用表别名，通过字段前缀区分不同表中的字段

查询条件中的限制条件要写在表连接条件前

尽量使用索引的字段做为查询条件

举例子：

product ---产品表

category-----分类表

左连接：----（外连接）

SELECT product.product_name,category.category_name

FROM product

LEFT JOIN category

on product.category_id=category.id

把左边的表（product）的表都查出来无论是否符合条件显示右边表（category）符合条件的

右连接----（外连接）

SELECT product.product_name,category.category_name

FROM product

RIGHT JOIN category

on product.category_id=category.id

把右边的表（category）的表都查出来无论是否符合条件显示左边表（product）符合条件的

内连接查询

对某些表间的某些类做比较操作，并列出这些表中与链接条件想匹配的行,只显示多张表中的满足条件的数据

SELECT category.category_name,product.product_name FROM product INNER JOIN category on category.id = product.category_id;

和

所以在最新商品这边适合用内连接

这个表从字面意思应该能知道按时间排序

SELECT iweb_goods.name,iweb_goods.img,iweb_goods.market_price,

iweb_goods.sell_price,iweb_goods.id,iweb_commend_goods.goods_id,

iweb_commend_goods.commend_id,iweb_goods.up_time

FROM iweb_goods

INNER JOIN iweb_commend_goods on

iweb_goods.id = iweb_commend_goods.goods_id and

iweb_commend_goods.commend_id=1 GROUP BY iweb_goods.up_time DESC LIMIT 8;

热卖商品：

SELECT iweb_goods.name,iweb_goods.img,

iweb_goods.sell_price,iweb_goods.id,iweb_commend_goods.goods_id,

iweb_commend_goods.commend_id

FROM iweb_goods

INNER JOIN iweb_commend_goods on

iweb_goods.id = iweb_commend_goods.goods_id and

iweb_commend_goods.commend_id=3 ORDER BY iweb_goods.up_time DESC LIMIT 8;

服饰鞋帽

从这里可以看出跟分类表商品表商品扩展表有关，涉及到多表查询他们属于男装女装运动装里取出来的

-- 1，先取出服饰鞋帽以及它二级分类的id

-- SELECT * FROM iweb_category WHERE parent_id = 57 or id =57

-- 2,取服饰鞋帽ID以及二级分类以及三级分类

SELECT * FROM iweb_category WHERE parent_id in

(SELECT id FROM iweb_category WHERE parent_id = 57 or id =57 ) or id =57

-- 这时发现category 和 goods表无关系需要和extend表关联根据三级分类的ID

子查询

当进行查询的时候，需要的条件是另外一个select语句的结果，这时候就要用到子查询

select g.name, g.img, g.sell_price, g.market_price from iweb_category as c inner join iweb_category_extend as e on c.id=e.category_id inner join iweb_goods as g on e.goods_id=g.id where c.id in(select id from iweb_category where parent_id in (select id from iweb_category where parent_id=57 or id=57 ) or id=57) order by g.up_time desc limit 8

这里in是=的意思

品牌列表最新评论帮助信息

数据库之补充知识：

与其他数据库例如Oracle 和SQL Server等数据库中只有一种存储引擎不同的是，MySQL有一个被称为“Pluggable Storage Engine Architecture”(可替换存储引擎架构)的特性，也就意味着MySQL数据库提供了多种存储引擎。用户可以根据不同的需求为数据表选择不同的存储引擎，用户也可以根据自己的需要编写自己的存储引擎。MySQL数据库在实际的工作中其实分为了语句分析层和存储引擎层，其中语句分析层就主要负责与客户端完成连接并且事先分析出SQL语句的内容和功能，而存储引擎层则主要负责接收来自语句分析层的分析结果，完成相应的数据输入输出和文件操作。简而言之，就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。因为在关系数据库中数据的存储是以表的形式存储的，所以存储引擎也可以称为表类型（即存储和操作此表的类型）。

https://blog.csdn.net/m0_37888031/article/category/7143403

>show engines

想要查看我们的数据表使用了什么存储引擎，【show】命令，语法如下：

SHOW CREATE TABLE 表名;

变更我们存储表的存储引擎将使用到的是我们前面使用过的【ALTER】命令，语法如下：

ALTER TABLE 表名 ENGINE=新引擎

事务处理特性：

原子性一致性持久性隔离性

--------想要使用处理，我们必须将我们的数据表的存储引擎设置为【InnoDB】

原子性：一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

一致性：一致性是指事务必须使数据库从一个一致的状态变到另外一个一致的状态，也就是执行事务之前和之后的状态都必须处于一致的状态。

隔离性：是指当多个用户并发访问数据库时，不能被其他事务的操作所干扰，多个并发事务之间要相互隔离。数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）

持久性:是指一个事务一旦被提交了，那么对于数据库中的数据改变就是永久性的，即便是在数据库系统遭遇到故障的情况下也不会丢失提交事务的操作

自动提交模式：

自动提交事务是SQL Server默认的事务处理方式，当任何一条有效的SQL语句被执行后，它对数据库所做的修改都将会被自动提交，如果发生错误，则将会自动回滚并返回错误信息。
在自动提交事务的模式中，有时SQL Server可能回滚了整个批处理，在这种情况下只有编译错误才会使整个事务被回滚，从而使所有SQL语句都没有被执行。

我们想要查看当前提交的模式可以使用【SELECT】语句

SELECT@@AUTOCOMMIT; 0：未开启；1：开启

修改自动提交模式

修改自动提交模式使用的是【SET】语句：

将自动提交模式设置为OFF的语法是：SET AUTOCOMMIT =0;

将自动提交模式设置为ON的语法是：SET AUTOCOMMIT =1;

Begin（或START TRANSACTION） : 开始事务

commit : 提交事务

rollback : 回滚事务

简单事务回滚

mysql> ALTER TABLE user ENGINE = InnoDB; //修改存储引擎

Query OK, 0 rows affected (0.59 sec)

Records: 0 Duplicates: 0 Warnings: 0

mysql> SHOW CREATE TABLE user; //查看是否修改成功

+——-+—————————————————————————————————————————————————————————————————————————-+

| Table | Create Table |

| user | CREATE TABLE user (

userId char(5) CHARACTER SET latin1 NOT NULL,

name varchar(30) DEFAULT NULL,

sex char(1) CHARACTER SET latin1 DEFAULT ‘0’,

PRIMARY KEY (userId)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

1 row in set (0.00 sec)

mysql> BEGIN; //开启事务

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM user; //确认数据

+——–+——–+——+

| userId | name | sex |

+——–+——–+——+

| 1 | 张三 | 0 |

| 2 | 李四 | 1 |

| 3 | 李四 | 0 |

| 4 | 王五 | 0 |

| 5 | 小张 | 1 |

| 6 | 张三丰 | 1 |

| 7 | NULL | 0 |

+——–+——–+——+

7 rows in set (0.00 sec)

mysql> DELETE FROM user; //删除数据

Query OK, 7 rows affected (0.00 sec)

mysql> SELECT * FROM user; //查看是否删除成功

Empty set (0.00 sec)

mysql> ROLLBACK; //回滚

Query OK, 0 rows affected (0.05 sec)

mysql> SELECT * FROM user; //查看是否回滚成功

+——–+——–+——+

| userId | name | sex |

+——–+——–+——+

| 1 | 张三 | 0 |

| 2 | 李四 | 1 |

| 3 | 李四 | 0 |

| 4 | 王五 | 0 |

| 5 | 小张 | 1 |

| 6 | 张三丰 | 1 |

| 7 | NULL | 0 |

+——–+——–+——+

7 rows in set (0.00 sec)

部分回滚：

mysql> BEGIN; //开启事务

Query OK, 0 rows affected (0.00 sec) //插入一条新的数据

mysql> INSERT INTO user VALUE(8,”WANG”,1);

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM user; //查看是否插入成功

+——–+——–+——+

| userId | name | sex |

+——–+——–+——+

| 1 | 张三 | 0 |

| 2 | 李四 | 1 |

| 3 | 李四 | 0 |

| 4 | 王五 | 0 |

| 5 | 小张 | 1 |

| 6 | 张三丰 | 1 |

| 7 | NULL | 0 |

| 8 | WANG | 1 |

+——–+——–+——+

8 rows in set (0.00 sec)

mysql> SAVEPOINT sk; //保存节点

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO user VALUE(9,”HONG”,0); //插入第二条数据

Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM user; //查看是否插入成功

+——–+——–+——+

| userId | name | sex |

+——–+——–+——+

| 1 | 张三 | 0 |

| 2 | 李四 | 1 |

| 3 | 李四 | 0 |

| 4 | 王五 | 0 |

| 5 | 小张 | 1 |

| 6 | 张三丰 | 1 |

| 7 | NULL | 0 |

| 8 | WANG | 1 |

| 9 | HONG | 0 |

+——–+——–+——+

9 rows in set (0.00 sec)

mysql> ROLLBACK TO SAVEPOINT sk; //回到保存节点

Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM user; //查看是否回退成功

+——–+——–+——+

| userId | name | sex |

+——–+——–+——+

| 1 | 张三 | 0 |

| 2 | 李四 | 1 |

| 3 | 李四 | 0 |

| 4 | 王五 | 0 |

| 5 | 小张 | 1 |

| 6 | 张三丰 | 1 |

| 7 | NULL | 0 |

| 8 | WANG | 1 |

+——–+——–+——+

8 rows in set (0.00 sec)

注意：

下面的四条语句在事务处理中是不可进行事务回滚的,也就是这四条语句一旦执行，就立刻被提交

DROP DATABASE;

DROP TABLE;

DROP;

ALTER TABLE;

使用联合(UNION)来代替手动创建的临时表

MySQL从4.0的版本开始支持union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用union来创建查询的时候，我们只需要用UNION作为关键字把多个select语句连接起来就可以了，要注意的是所有select语句中的字段数目要想同。下面的例子就演示了一个使用UNION的查询。

SELECTName,PhoneFROMclientUNION

SELECTName,BirthDateFROMauthorUNION

SELECTName,SupplierFROMproduct

事务

尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。

BEGIN;

INSERT INTO salesinfo SET CustomerID=14;

UPDATE inventory SET Quantity=11 WHERE item='book';

COMMIT;

事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。

锁定表（LOCK和UNLOCK TABLES）

尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE SELECT Quantity FROM inventory WHERE Item='book';

...

UPDATE inventory SET Quantity=11 WHERE Item='book';UNLOCK TABLES

这里，我们用一个select语句取出初始数据，通过一些计算，用update语句将新值更新到表中。包含有WRITE关键字的LOCK TABLE语句可以保证在UNLOCK TABLES命令被执行之前，不会有其它的访问来对inventory进行插入、更新或者删除的操作。

可将表的名称放在LOCK TABLES关键字后面，后跟一个锁类型。 MySQL提供两种锁类型：READ和WRITE

可以使用SHOW PROCESSLIST 查看

使用外键

锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。

例如，外键可以保证每一条销售记录都指向某一个存在的客户。在这里，外键可以把customerinfo表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。

CREATE TABLE customerinfo( CustomerID INT NOT NULL,

PRIMARY KEY(CustomerID)) TYPE =INNODB;

CREATE TABLE salesinfo( SalesID INT NOT NULL,Customer ID INT NOT NULL,

PRIMARY KEY(CustomerID,SalesID),

FOREIGN KEY(CustomerID) REFERENCES customerinfo(CustomerID)

ON DELETE CASCADE)TYPE=INNODB;

注意例子中的参数“ONDELETECASCADE”。该参数保证当customerinfo表中的一条客户记录被删除的时候，salesinfo表中所有与该客户相关的记录也会被自动删除。如果要在MySQL中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表InnoDB类型。该类型不是MySQL表的默认类型。定义的方法是在CREATE TABLE语句中加上TYPE=INNODB。如例中所示。

建立外键的前提：

被约束字段与外键的数据类型必须相同

被约束字段需要设置为索引，外键需要设置为 PRIMARY --主要的

外键作用：使两张表形成关联，外键只能引用从表中的列的值！

指定从表关键字： foreign key (列名)

引用外键关键字： references <外键表名> (外键列名)

# 事件触发（级联操作）限制： on delete 和 on update

可设参数 cascade (跟随外键改动)--级联（是对表的主键或是外键使用），强烈推荐，能够保存数据一致性

restrict (限制主表中的外键改动)

[默认] no action

Sql优化

1、使用索引

尽量避免全表扫描，首先应考虑在where及order by，group by涉及的列上建立索引。

----------应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null，备注、描述、评论之类的可以设置为 NULL，其他的，最好不要使用NULL。

----------应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。
----------应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，.in 和 not in 也要慎用，否则会导致全表扫描、（对于连续的数值，能用 between 就不要用 in 了）

----------应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描 select id from t where num/2 = 100 ，应改为: select id from t where num = 100*2

-----------应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描 select id from t where substring(name,1,3) = ’abc’ -–name以abc开头的id，应改为：select id from t where name like 'abc%'

概括：不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引

索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

Update 语句，如果只更改1、2个字段，不要Update全部字段，否则频繁调用会引起明显的性能消耗，同时带来大量日志
对于多张大数据量（这里几百条就算大了）的表JOIN，要先分页再JOIN，否则逻辑读会很高，性能很差
尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
尽可能的使用 varchar/nvarchar 代替 char/nchar，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

7.临时表

--------尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

---------避免频繁创建和删除临时表，以减少系统表资源的消耗。临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

---------在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

---------如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

-------- 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。

---------使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

---------与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
尽量避免大事务操作，提高系统并发能力

9，尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理

实际案例分析：拆分大的 DELETE 或INSERT 语句，批量提交SQL语句

如果你需要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。Apache 会有很多的子进程或线程。所以，其工作起来相当有效率，而我们的服务器也不希望有太多的子进程，线程和数据库链接，这是极大的占服务器资源的事情，尤其是内存。如果你把你的表锁上一段时间，比如30秒钟，那么对于一个有很高访问量的站点来说，这30秒所积累的访问进程/线程，数据库链接，打开的文件数，可能不仅仅会让你的WEB服务崩溃，还可能会让你的整台服务器马上挂了。所以，如果你有一个大的处理，你一定把其拆分，使用 LIMIT oracle(rownum),sqlserver(top)条件是一个好的方法。下面是一个mysql示例：

while(1){

//每次只做1000条

mysql_query(“delete from logs where log_date <= ’2012-11-01’ limit 1000”);

if(mysql_affected_rows() == 0){

//删除完成，退出！

break；

}

//每次暂停一段时间，释放表让其他进程/线程访问。

usleep(50000)