1创建存储过程语法

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语句。带参数的一定要定义参数类型，是字符型的还要定义长度，给参数加默认值是可选的。

2存储过程的优点和缺点

优点：

1提高性能

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

2降低网络开销

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

3便于进行代码移植

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

4更强的安全性

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

劣势：

1逻辑处理吃力

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

2修改参数复杂

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

3开发调试复杂

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

4无法应用缓存

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

5不支持群集

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