以下是存储过程是一个示例：
create Procedure [dbo].[Test]
@OrderInfoID AS INT=-1,
@GroupInfoID as int=-1,
@AccountId AS INT =-1,
@BuyerName NVARCHAR(255)='',
@BuyerAccount NVARCHAR(255)='',
@Address nvarchar(500)='',
@eBayItemNumber NVARCHAR(20)='',
@eBayItemName nvarchar(500)='',
@Sum money=-1,
@SalesRecordNo nvarchar(20)='',
@IsPaid AS CHAR(1)='',
@PaypalTransactionID NVARCHAR(255)='',
@IsSendOff as char(1)='',
@IsMaintainPostage as money=1,
@eBayOrderId nvarchar(20)='',
@PostOrderDateFrom datetime='1900-1-1',
@PostOrderDateTo datetime='1900-1-1'
AS
SELECT oi.*, ao.DifferPrice
FROM table1 oi WITH(NOLOCK)
LEFT JOIN dbo.table2 ao ON ao.OrderGUID = oi.GUID
WHERE (@OrderInfoID = -1 OR OrderInfoID = @OrderInfoID) AND
(@GroupInfoID=-1 OR oi.GroupInfoID=@GroupInfoID) AND
(@AccountId = - 1 OR AccountId = @AccountId) AND
(@IsPaid = '' OR IsPaid = @IsPaid) AND
(@PaypalTransactionID = '' OR PaypalTransactionID = @PaypalTransactionID) AND
(@Sum=-1 OR TotalPrice=@Sum) AND
(@BuyerName='' OR BuyerName like '%'+@BuyerName+'%') AND
(@BuyerAccount='' OR BuyerAccount like '%'+@BuyerAccount+'%') AND
(@Address='' OR Address like '%'+@Address+'%') AND
(@eBayItemNumber='' OR eBayItemNumber like '%'+@eBayItemNumber+'%') AND
(@eBayOrderId='' OR eBayOrderId like '%'+@eBayItemNumber+'%') AND
(@eBayItemName='' OR eBayItemName like '%'+@eBayItemName+'%') AND
(@SalesRecordNo='' OR SalesRecordNo=@SalesRecordNo) AND
(@IsSendOff='' OR IsSendOff=@IsSendOff) AND
(@IsMaintainPostage=1 OR (Postage<=0.1 AND SalePrice<=1)) AND
(@PostOrderDateFrom='1900-1-1' or (PostOrderDate>=@PostOrderDateFrom and PostOrderDate<=@PostOrderDateTo))
ORDER BY PostOrderDate desc
仅仅讨论一下参数带默认值而使用OR的这方面，这样的存储过程性能能高到哪里去？
如果采用拼接字符串的方式，存储过程又很难维护，怎么办？
------解决思路----------------------
推荐一下，让更多人参与讨论，我想听听一线开发人员的声音
------解决思路----------------------
这种随机查询老老实实在程序中拼 SQL 好了（当然会通过 SqlCommand 避免直接拼字段值格式不一致的问题）。
至少全是 AND 没有 OR 的条件还有可能被优化。
用 SP 多此一举，没有任何好处。
------解决思路----------------------
这个是我们公司的系统中的存储过程，一开始由于需求人员不严格控制需求，导致用户需要什么就做什么，直接导致数据量百万级，数据就顶不住了，经常死锁阻塞。
我曾经跟开发人员讨论过，这样做程序是不行的，我们这个应用程序不是报表一类的程序，要求的就是效率，可惜无人理会。
我们公司是生产超级跑车的。一开始因为销售人员不严格控制，导致几个想买拉煤车的煤老板也成了客户。于是轻量化跑车车架有点架不住了，车子经常跑着跑着就散架了。
我曾经和工程师们讨论过。这样做跑车是不行的，我们的跑车不是那种专门在平坦的高速路上跑的，要追求载货量，可惜无人理会。
SB，你知道为什么无人理会么？因为工程师们在想“ntmd让销售来改进啊”
------解决思路----------------------
我是开发的
看来不是巧合，确实有人喜欢这种做法
我目前所在的公司，见过一个系统的查询也是这种方式实现的，然后这个系统各种被骂，很难维护
因为数据比较少，性能没有凸显出来
查询条件中有or的情况下，确实会引起并行查询，不过并行查询的弊端我没研究过
如果非要用这种方式实现的话，建议在存储过程中拼动态sql（where条件），最起码sql看起来不会这么邋遢
这个感觉在应用端控制起来更清晰吧，我个人觉得写sql是程序员的基本素质
我前一个公司挺正规的，这种工作是不可能交给SP去实现的，因为数据量也比较大，任何查询必须选择某些个条件
如果说数据量达到一定程度，又要随意查询，又要保证性能，那真的就不好办了
------解决思路----------------------
换做我写的话 肯定是一大堆动态拼接 一堆IF ELSE去过滤条件了
------解决思路----------------------
这种随机查询讲优化就是扯淡，优化出的索引比数据还大，还要不要更新数据了！
------解决思路----------------------
我觉得现在主要是解决性能问题，性能问题应该是写法造成，如果确认是存储过程中的写法造成的，就去优化这种写法，如果不是写法造成的，那就是放在应用程序中写sql也解决不了，我个人感觉不管是哪种方式造成的问题，能不能解决，怎么解决，都应该反馈出来，领导是干嘛的？就是解决问题做决定的，如果领导都做不了主，那你就随波逐流地混吧，多混一天是一天，这种领导跟着也没啥意义
如果你自己私下吭哧吭哧累个半死，解决了还好，解决不了还被黑锅