जैसे ऑपरेटर इतनी धीमी खोज कर रहा है

Question 1

मेरे पास एक प्रश्न है जो तालिका से परिणाम खोज रहा है, यदि कोई पंक्ति किसी विशिष्ट वस्तु से मेल खाती है तो यह परिणाम प्रदान करेगी।

तो, यह एक 12 अक्षर की संख्या है।

तो कार्यक्षमता यह है कि यदि उपयोगकर्ता ने 414 के रूप में एक संख्या प्रदान की है तो यह '% 414%' की तरह खोज करेगा।

और यदि संख्या की लंबाई 6 अंकों से अधिक है तो यह '4146144%' की तरह खोजेगा

परिणामस्वरूप क्वेरी इतनी धीमी हो रही है क्योंकि हमारे पास 20 मिलियन रिकॉर्ड हैं।

क्या आप कृपया मुझे उस समस्या को ठीक करने के लिए कोई विकल्प प्रदान कर सकते हैं।

कंपनी किसी एपीआई या किसी अन्य चीज का उपयोग करने की अनुमति नहीं दे रही है।

 SELECT  distinct TOP (15) bt_id AS [Key]
       , UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description]   
 FROM    fcbillto 
 WHERE   bt_id   like '%' + @SearchTerm + '%'
 OR      bt_desc like '%' + @SearchTerm + '%'

यदि पूर्ण पाठ स्कैन समाधान है, तो क्या मैं एक ही तालिका के लिए दो अलग-अलग कैटलॉग बना सकता हूं क्योंकि उपरोक्त कॉलम में से एक है जिस पर मुझे खोज करने की आवश्यकता है और दूसरी स्थिति में मैं उसी तालिका के किसी अन्य कॉलम पर खोज रहा हूं। तो, मुझे चाहिए दो रिपॉजिटरी बनाने के लिए।

sql-server sql-server-2008 tsql

-1

Ayush Kalia 7 फरवरी 2017, 12:23

Bt_desc ntext है? क्या आपको वास्तव में विवरण में संख्या की खोज करने की आवश्यकता है, या जब आप केवल bt_id में खोज करते हैं तो यह पर्याप्त रूप से सटीक हो सकता है?

–

Cee McSharpface

7 फरवरी 2017, 12:29

दोनों डेटा प्रकार चार के हैं, बीटी_आईडी चार(12) और बीटी_डीएससी चार (40) के हैं। चूंकि डीबी पहले डिजाइन किया गया था इसलिए मैं डिजाइन भाग पर अपडेट नहीं कर सकता

–

Ayush Kalia

7 फरवरी 2017, 12:32

1

चीजों को गति देने का एक तरीका उचित अनुक्रमण होगा: यह, या संभावित रूप से यह या यह< /ए>

@dlatikay: अनुक्रमण की कोई भी मात्रा LIKE '%414%' खोजों (एक प्रमुख % वाइल्डकार्ड के साथ) के साथ प्रश्नों को गति नहीं दे सकती है - वे हमेशा पूर्ण तालिका स्कैन होने वाली हैं और इस प्रकार धीमी हैं ......

–

marc_s

7 फरवरी 2017, 13:17

Answer

आपके पास दो समस्याएं हैं जो आपकी क्वेरी के खड़े होने पर किसी भी अनुक्रमणिका के कुशल उपयोग को रोकती हैं:

1) OR क्लॉज। SQL bt_id या bt_desc पर OR क्लॉज के साथ किसी इंडेक्स का उपयोग नहीं कर सकता है क्योंकि एक कॉलम पर फ़िल्टर करने के लिए इंडेक्स का उपयोग करने से दूसरे कॉलम पर विधेय को पूरा करने वाली मान्य पंक्तियों को खत्म किया जा सकता है। यदि आपके पास दोनों स्तंभों पर एक अनुक्रमणिका थी तो आप दोनों मानदंडों को पूरा करने वाली पंक्तियों को प्राप्त करने के लिए UNION का उपयोग कर सकते हैं (या यदि आप भाग्यशाली हैं तो ऑप्टिमाइज़र इसे अंडर-द-हूड कर सकता है) लेकिन इंडेक्स का उपयोग नहीं किया जा सकता है जैसा कि चीजें खड़ी हैं क्योंकि ...

2) एक LIKE एक अग्रणी % के साथ एक इंडेक्स पर खोज नहीं कर सकता क्योंकि इंडेक्स को प्रमुख वर्णों के आधार पर क्रमबद्ध किया जाता है। यदि इसे स्ट्रिंग के बीच में वर्णों की तलाश करनी है तो यह पंक्तियों की तलाश के लिए अनुक्रमणिका का उपयोग नहीं कर सकता है। (इसका मतलब यह नहीं है कि यह सूचकांक को स्कैन नहीं करेगा क्योंकि यह स्वयं तालिका से छोटा है - इसलिए इस आधार पर अभी भी प्रदर्शन में सुधार हो सकता है)।

इसलिए आवश्यकताओं में बदलाव के बिना वास्तविक प्रदर्शन सुधार देखना मुश्किल साबित हो सकता है। यदि आप आवश्यकताओं को इस तरह बदल सकते हैं कि खोज केवल प्रमुख वर्णों पर है (या किसी अन्य अनुक्रमित कॉलम पर क्वेरी को सीमित करें) तो यह तेज़ होगा (bt_id और bt_desc पर अनुक्रमणिका मानते हुए):

SELECT  TOP (15) bt_id AS [Key]
   ,  UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description]   

FROM 
(SELECT  bt_id
   , bt_desc 
 FROM    fcbillto 
 WHERE   bt_id   like @SearchTerm + '%'

UNION

SELECT  bt_id
   , bt_desc   
 FROM    fcbillto 
 WHERE   bt_desc like @SearchTerm + '%') search

ORDER BY bt_id -- I presume?

पूर्ण टेक्स्ट इंडेक्स कॉलम के भीतर शब्दों को खोजने के लिए डिज़ाइन किए गए हैं - आपके पास केवल वर्ण हैं जो मदद नहीं करेंगे।

2

strickt01 7 फरवरी 2017, 15:30

मेरा मानना है कि यह संघ समाधान प्रश्न से क्वेरी की तुलना में धीमा है, क्योंकि क्वेरी से पहले धीमे संघ ने शेष पंक्तियों को पहले 15 से परे समाप्त कर दिया है

–

t-clausen.dk

7 फरवरी 2017, 16:38

यह ORDER BY की आवश्यकता पर निर्भर करता है। मैंने यह मानते हुए एक जोड़ा कि यह प्रासंगिक होगा। यदि एक की आवश्यकता है तो मूल क्वेरी को पूरी तालिका को स्कैन करना होगा ताकि यह पता लगाया जा सके कि कौन सी पंक्तियां पहले 15 बनाती हैं। यदि नहीं, तो मानदंड को पूरा करने वाली पंक्तियों के आधार पर मूल क्वेरी तेज हो सकती है। हालांकि इसमें एक क्लस्टर इंडेक्स स्कैन शामिल होगा जिसमें लॉकिंग के लिए भयानक प्रभाव पड़ते हैं।

–

strickt01

7 फरवरी 2017, 16:55

Answer

इसको आजमाओ।

SELECT distinct TOP (15) 
  bt_id AS [Key], 
  UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description] 
FROM fcbillto 
WHERE charindex(@SearchTerm, bt_id) > 0 OR charindex(@SearchTerm, bt_desc) > 0

0

Saravanan Yadav 7 फरवरी 2017, 14:56

धन्यवाद सरवनन क्या आप कृपया मुझे फीचर का नाम प्रदान कर सकते हैं। जैसे यह कुछ और पसंद नहीं है।ताकि मैं इसके पक्ष और विपक्ष को जानने से पहले जान सकूं और अपने वरिष्ठों को इस बारे में सुझाव दे सकूं।

–

Ayush Kalia

7 फरवरी 2017, 15:02

हालाँकि: charindex(@SearchTerm, bt_id)> 0 '%@SearchTerm%' जैसे url के समान है, लेकिन आंतरिक रूप से वे किसी तरह अलग तरह से काम करते हैं। कुछ लोगों के लिए LIKE अभिव्यक्ति तेजी से निकली, दूसरों के लिए CHARINDEX विधि। शायद यह क्वेरी, प्रोसेसर की संख्या, ऑपरेटिंग सिस्टम, जो भी हो, पर निर्भर करता है। यह एक कोशिश के काबिल हो सकता है। कृपया इसे अपने वरिष्ठों को दिखाएं। cc.davelozinski.com/sql/…

–

Saravanan Yadav

7 फरवरी 2017, 15:19

यह एक दिलचस्प लिंक है लेकिन यह एक कॉलम पर खोजों पर लागू होता है। यह एक इंडेक्स का उपयोग नहीं करता है (यह स्ट्रिंग के दोनों सिरों को देखता है) इसलिए पूरी तरह से कार्यों का परीक्षण कर रहा है - प्रदर्शन बढ़ाने के लिए इंडेक्स का उपयोग नहीं। वर्तमान समस्या 20 मिलियन पंक्ति तालिका में तालिका/क्लस्टर इंडेक्स स्कैन के कारण क्वेरी के साथ निहित है, इसलिए जब तक कि किसी प्रकार के इंडेक्स उपयोग को लागू नहीं किया जा सकता है, वहां कुछ बहुत ही नकारात्मक प्रदर्शन प्रभाव होंगे (कम से कम लॉकिंग नहीं!)।

–

strickt01

7 फरवरी 2017, 16:04

Question 2

आपके पास दो समस्याएं हैं जो आपकी क्वेरी के खड़े होने पर किसी भी अनुक्रमणिका के कुशल उपयोग को रोकती हैं:

1) OR क्लॉज। SQL bt_id या bt_desc पर OR क्लॉज के साथ किसी इंडेक्स का उपयोग नहीं कर सकता है क्योंकि एक कॉलम पर फ़िल्टर करने के लिए इंडेक्स का उपयोग करने से दूसरे कॉलम पर विधेय को पूरा करने वाली मान्य पंक्तियों को खत्म किया जा सकता है। यदि आपके पास दोनों स्तंभों पर एक अनुक्रमणिका थी तो आप दोनों मानदंडों को पूरा करने वाली पंक्तियों को प्राप्त करने के लिए UNION का उपयोग कर सकते हैं (या यदि आप भाग्यशाली हैं तो ऑप्टिमाइज़र इसे अंडर-द-हूड कर सकता है) लेकिन इंडेक्स का उपयोग नहीं किया जा सकता है जैसा कि चीजें खड़ी हैं क्योंकि ...

2) एक LIKE एक अग्रणी % के साथ एक इंडेक्स पर खोज नहीं कर सकता क्योंकि इंडेक्स को प्रमुख वर्णों के आधार पर क्रमबद्ध किया जाता है। यदि इसे स्ट्रिंग के बीच में वर्णों की तलाश करनी है तो यह पंक्तियों की तलाश के लिए अनुक्रमणिका का उपयोग नहीं कर सकता है। (इसका मतलब यह नहीं है कि यह सूचकांक को स्कैन नहीं करेगा क्योंकि यह स्वयं तालिका से छोटा है - इसलिए इस आधार पर अभी भी प्रदर्शन में सुधार हो सकता है)।

इसलिए आवश्यकताओं में बदलाव के बिना वास्तविक प्रदर्शन सुधार देखना मुश्किल साबित हो सकता है। यदि आप आवश्यकताओं को इस तरह बदल सकते हैं कि खोज केवल प्रमुख वर्णों पर है (या किसी अन्य अनुक्रमित कॉलम पर क्वेरी को सीमित करें) तो यह तेज़ होगा (bt_id और bt_desc पर अनुक्रमणिका मानते हुए):

SELECT  TOP (15) bt_id AS [Key]
   ,  UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description]   

FROM 
(SELECT  bt_id
   , bt_desc 
 FROM    fcbillto 
 WHERE   bt_id   like @SearchTerm + '%'

UNION

SELECT  bt_id
   , bt_desc   
 FROM    fcbillto 
 WHERE   bt_desc like @SearchTerm + '%') search

ORDER BY bt_id -- I presume?

पूर्ण टेक्स्ट इंडेक्स कॉलम के भीतर शब्दों को खोजने के लिए डिज़ाइन किए गए हैं - आपके पास केवल वर्ण हैं जो मदद नहीं करेंगे।

2

strickt01 7 फरवरी 2017, 15:30

मेरा मानना है कि यह संघ समाधान प्रश्न से क्वेरी की तुलना में धीमा है, क्योंकि क्वेरी से पहले धीमे संघ ने शेष पंक्तियों को पहले 15 से परे समाप्त कर दिया है

–

t-clausen.dk

7 फरवरी 2017, 16:38

यह ORDER BY की आवश्यकता पर निर्भर करता है। मैंने यह मानते हुए एक जोड़ा कि यह प्रासंगिक होगा। यदि एक की आवश्यकता है तो मूल क्वेरी को पूरी तालिका को स्कैन करना होगा ताकि यह पता लगाया जा सके कि कौन सी पंक्तियां पहले 15 बनाती हैं। यदि नहीं, तो मानदंड को पूरा करने वाली पंक्तियों के आधार पर मूल क्वेरी तेज हो सकती है। हालांकि इसमें एक क्लस्टर इंडेक्स स्कैन शामिल होगा जिसमें लॉकिंग के लिए भयानक प्रभाव पड़ते हैं।

–

strickt01

7 फरवरी 2017, 16:55

Question 3

इसको आजमाओ।

SELECT distinct TOP (15) 
  bt_id AS [Key], 
  UPPER(rtrim(ltrim(bt_id)))+' - '+UPPER(rtrim(ltrim(bt_desc))) AS [Description] 
FROM fcbillto 
WHERE charindex(@SearchTerm, bt_id) > 0 OR charindex(@SearchTerm, bt_desc) > 0

0

Saravanan Yadav 7 फरवरी 2017, 14:56

धन्यवाद सरवनन क्या आप कृपया मुझे फीचर का नाम प्रदान कर सकते हैं। जैसे यह कुछ और पसंद नहीं है।ताकि मैं इसके पक्ष और विपक्ष को जानने से पहले जान सकूं और अपने वरिष्ठों को इस बारे में सुझाव दे सकूं।

–

Ayush Kalia

7 फरवरी 2017, 15:02

हालाँकि: charindex(@SearchTerm, bt_id)> 0 '%@SearchTerm%' जैसे url के समान है, लेकिन आंतरिक रूप से वे किसी तरह अलग तरह से काम करते हैं। कुछ लोगों के लिए LIKE अभिव्यक्ति तेजी से निकली, दूसरों के लिए CHARINDEX विधि। शायद यह क्वेरी, प्रोसेसर की संख्या, ऑपरेटिंग सिस्टम, जो भी हो, पर निर्भर करता है। यह एक कोशिश के काबिल हो सकता है। कृपया इसे अपने वरिष्ठों को दिखाएं। cc.davelozinski.com/sql/…

–

Saravanan Yadav

7 फरवरी 2017, 15:19

यह एक दिलचस्प लिंक है लेकिन यह एक कॉलम पर खोजों पर लागू होता है। यह एक इंडेक्स का उपयोग नहीं करता है (यह स्ट्रिंग के दोनों सिरों को देखता है) इसलिए पूरी तरह से कार्यों का परीक्षण कर रहा है - प्रदर्शन बढ़ाने के लिए इंडेक्स का उपयोग नहीं। वर्तमान समस्या 20 मिलियन पंक्ति तालिका में तालिका/क्लस्टर इंडेक्स स्कैन के कारण क्वेरी के साथ निहित है, इसलिए जब तक कि किसी प्रकार के इंडेक्स उपयोग को लागू नहीं किया जा सकता है, वहां कुछ बहुत ही नकारात्मक प्रदर्शन प्रभाव होंगे (कम से कम लॉकिंग नहीं!)।

–

strickt01

7 फरवरी 2017, 16:04

जैसे ऑपरेटर इतनी धीमी खोज कर रहा है

2 जवाब

संबंधित सवाल

जुड़े हुए प्रश्न

नए सवाल

sql-server