SQL存储过程的详细用法，不信你看不懂（上）

创建存储过程

create proc | procedure procedure_name

   [{@参数数据类型} [=默认值] [output],

    {@参数数据类型} [=默认值] [output],

    ....

   ]

as

   SQL_statements

go

示例

create proc sp_test
@param1 int,
@param2 varchar(16)
as
select * from test
where id=@param1
and t_no=@param2;
go

上面就是一个简单的示例。存储过程在创建阶段可以带参数或不带参数，不带参数的一般是执行一些不需要传递参数的语句就可以完成的功能，带参数那就是需要传递参数的SQL语句，就像上面的示例，传递了两个参数给SQL语句。带参数的一定要定义参数类型，是字符型的还要定义长度，给参数加默认值是可选的。

存储过程的优点和缺点

优点：

1、提高性能SQL语句在创建过程时进行分析和编译。存储过程是预编译的，在首次运行一个存储过程时，查询优化器对其进行分析、优化，并给出最终被存在系统表中的存储计划，这样，在执行过程时便可节省此开销。

2、降低网络开销

存储过程调用时只需用提供存储过程名和必要的参数信息，从而可降低网络的流量。

3、便于进行代码移植

数据库专业人员可以随时对存储过程进行修改，但对应用程序源代码却毫无影响，从而极大的提高了程序的可移植性。

4、更强的安全性

1）系统管理员可以对执行的某一个存储过程进行权限限制，避免非授权用户对数据的访问

2）在通过网络调用过程时，只有对执行过程的调用是可见的。因此，恶意用户无法看到表和数据库对象名称、嵌入自己的 Transact-SQL 语句或搜索关键数据。
3）使用过程参数有助于避免 SQL 注入攻击。因为参数输入被视作文字值而非可执行代码，所以，攻击者将命令插入过程内的 Transact-SQL 语句并损害安全性将更为困难。
4）可以对过程进行加密，这有助于对源代码进行模糊处理。

劣势：

1、逻辑处理吃力 SQL本身是一种结构化查询语言，但不是面向对象的的，本质上还是过程化的语言，面对复杂的业务逻辑，过程化的处理会很吃力。同时SQL擅长的是数据查询而非业务逻辑的处理，如果如果把业务逻辑全放在存储过程里面，违背了这一原则。

2、修改参数复杂如果需要对输入存储过程的参数进行更改，或者要更改由其返回的数据，则您仍需要更新程序集中的代码以添加参数、更新调用，等等，这时候估计会比较繁琐了。

3、开发调试复杂

由于IDE的问题，存储过程的开发调试要比一般程序困难。    

4、无法应用缓存虽然有全局临时表之类的方法可以做缓存，但同样加重了数据库的负担。如果缓存并发严重，经常要加锁，那效率实在堪忧。

5、不支持群集数据库服务器无法水平扩展，或者数据库的切割（水平或垂直切割）。数据库切割之后，存储过程并不清楚数据存储在哪个数据库中。

存储过程的具体应用

基础应用

1、创建不带参数的存储过程

示例：查询订单表中订单总数

--查询存储过程
IF OBJECT_ID (N'PROC_ORDER_COUNT', N'P') IS NOT NULL
   DROP procedure PROC_ORDER_COUNT;
GO
CREATE procedure PROC_ORDER_COUNT
AS
   SELECT COUNT(OrderID) FROM Orders;
GO
--执行上述存储过程：
EXEC PROC_ORDER_COUNT;

2、创建带参数的存储过程

示例：根据城市查询订单数量

--查询存储过程，根据城市查询总数
IF OBJECT_ID (N'PROC_ORDER_COUNT', N'P') IS NOT NULL
   DROP procedure PROC_ORDER_COUNT;
GO
CREATE procedure PROC_ORDER_COUNT(@city nvarchar(50))
AS
   SELECT COUNT(OrderID) FROM Orders WHERE City=@city
GO
--执行上述存储过程：
EXEC PROC_ORDER_COUNT  N'GuangZhou';