মাইএসকিউএল - সারি গণনা করার জন্য গণনা (*) এবং তথ্য_সেমি.টিবিল ব্যবহারের মধ্যে পার্থক্য

16

আমার টেবিলে কয়েক মিলিয়ন সারি রয়েছে এমন সারিগুলির সংখ্যা গণনা করার জন্য আমি একটি দ্রুত উপায় চাই। স্ট্যাক ওভারফ্লোতে আমি " মাইএসকিউএল: সারি সংখ্যা গণনার দ্রুততম উপায় " পোস্টটি পেয়েছি , যা দেখে মনে হচ্ছে এটি আমার সমস্যার সমাধান করবে। বায়ুয়া এই উত্তরটি প্রদান করেছিল:

SELECT
    table_rows "Rows Count"
FROM
    information_schema.tables
WHERE
    table_name="Table_Name"
AND
    table_schema="Database_Name";

যা আমি পছন্দ করেছি কারণ এটি স্ক্যানের পরিবর্তে দেখার মতো লাগে তাই এটি দ্রুত হওয়া উচিত, তবে আমি এটির বিরুদ্ধে পরীক্ষা করার সিদ্ধান্ত নিয়েছি

SELECT COUNT(*) FROM table

পারফরম্যান্সের পার্থক্য কত ছিল তা দেখতে।

দুর্ভাগ্যক্রমে আমি নীচের মত বিভিন্ন উত্তর পেয়েছি :

প্রশ্ন

উত্তরগুলি প্রায় 2 মিলিয়ন সারি দ্বারা পৃথক কেন? আমি যে কোয়েরিটি অনুমান করছি যে পুরো টেবিল স্ক্যানটি করে সেগুলি আরও সঠিক সংখ্যা, তবে এই ধীর অনুসন্ধানটি না চালিয়ে আমি কী সঠিক নম্বর পেতে পারি?

আমি দৌড়েছি ANALYZE TABLE data_302, যা 0.05 সেকেন্ডে শেষ হয়েছে। যখন আমি আবার ক্যোয়ারী চালিয়েছি, এখন আমি 34384599 সারিগুলির একটি খুব কাছাকাছি ফলাফল পেয়েছি, তবে এটি এখনও select count(*)34906061 সারিগুলির মতো একই সংখ্যা নয় । টেবিলটি তাত্ক্ষণিকভাবে ফেরত বিশ্লেষণ করে পটভূমিতে প্রক্রিয়া করবে? আমি এটির মূল্যবান মনে করি এটি একটি পরীক্ষামূলক ডাটাবেস এবং বর্তমানে লিখিত হয় নি।

টেবিলটি কতটা বড় তা কাউকে বলার ক্ষেত্রে যদি কেউ নজর রাখে না তবে আমি সারি গণনাটি কিছুটা কোডে পাস করতে চেয়েছিলাম যা এই চিত্রটি ব্যবহার করে ডাটাবেস অনুসন্ধানের জন্য "সমান আকারের" অ্যাসিনক্রোনাস কোয়েরি তৈরি করতে পারে সমান্তরালভাবে, আলেকজান্ডার রুবিনের সমান্তরাল ক্যোয়ারী এক্সিকিউশনের সাথে ধীর ক্যোয়ারী পারফরম্যান্স বাড়ানো পদ্ধতির অনুরূপ । যেমনটি হ'ল, আমি সর্বাধিক আইডিটি পেয়ে SELECT id from table_name order by id DESC limit 1যাব এবং আশা করব যে আমার টেবিলগুলি খুব বেশি খণ্ডিত হবে না।

mysql mysql-5.6 count

— Programster
সূত্র

23

একটি সারণীতে সারিগুলি "গণনা" করার বিভিন্ন উপায় রয়েছে। কী সর্বোত্তম তা প্রয়োজনীয়তার উপর নির্ভর করে (গণনার যথাযথতা, কত ঘন ঘন সঞ্চালিত হয়, আমাদের পুরো টেবিলের গণনা প্রয়োজন বা ভেরিয়েবল whereএবং group byধারাগুলি ইত্যাদি))

ক) সাধারণ উপায়। শুধু তাদের গণনা ।
```
select count(*) as table_rows from table_name ; 
```
নির্ভুলতা : ক্যোয়ারির সময় 100% নির্ভুল গণনাটি চালানো হয়।
দক্ষতা : বড় টেবিলগুলির জন্য ভাল নয়। (মাইআইএসএএম টেবিলগুলির জন্য দর্শনীয়ভাবে দ্রুত তবে ইনোডিবি-র তুলনায় এতগুলি অসুবিধাগুলি হওয়ায় আজকাল কেউ মাইআইএসএএম ব্যবহার করছে না a "দর্শনীয়ভাবে দ্রুত" কেবল তখনই প্রয়োগ হয় পুরো মাইআইএসএএম টেবিলের সারিগুলি গণনা করার সময় - যদি ক্যোয়ারীর WHEREশর্ত থাকে তবে এটি এখনও টেবিল বা একটি সূচক স্ক্যান করতে হবে))
InnoDB টেবিলগুলির জন্য এটি টেবিলের আকারের উপর নির্ভর করে কারণ সঠিক গণনা পেতে ইঞ্জিনকে পুরো টেবিলটি বা একটি সম্পূর্ণ সূচি স্ক্যান করতে হবে। বড় টেবিল, ধীরে ধীরে এটি পায়।
খ) ব্যবহার SQL_CALC_FOUND_ROWSএবং FOUND_ROWS()। পূর্ববর্তী পদ্ধতির পরিবর্তে ব্যবহার করা যেতে পারে, আমরা যদি সারিগুলির একটি সংখ্যক সংখ্যক পাশাপাশি (পরিবর্তনও করে LIMIT) চাই তবে। আমি এটি পেজিংয়ের জন্য ব্যবহার করতে দেখেছি (কিছু সারি পেতে এবং একই সাথে জানতে হবে যে মোট কতগুলি রয়েছে এবং পেজেজের সংখ্যা গণনা করে)।
```
select sql_calc_found_rows * from table_name limit 0 ; 
select found_rows() as table_rows ;
```
নির্ভুলতা : আগের মতো।
দক্ষতা : আগের মত একই।
গ)information_schema সংযুক্ত প্রশ্ন হিসাবে টেবিলগুলি ব্যবহার করে :
```
select  table_rows
from    information_schema.tables
where   table_schema = 'database_name'
  and   table_name = 'table_name' ;
```
নির্ভুলতা : কেবল একটি আনুমানিক। যদি টেবিলটি ঘন ঘন সন্নিবেশ এবং মুছে ফেলার লক্ষ্য হয় তবে ফলাফলটি প্রকৃত গণনা থেকে দূরে থাকতে পারে। এটি ANALYZE TABLEপ্রায়শই চালানো দ্বারা উন্নত করা যেতে পারে ।
দক্ষতা : খুব ভাল, এটি টেবিলটি একেবারেই স্পর্শ করে না।
ঘ) ডাটাবেসে গণনা সংরক্ষণ করা (অন্যটিতে, "কাউন্টার" সারণীতে ) এবং টেবিলে একটি সন্নিবেশ করা, মোছা বা কাটানো প্রতিটি সময়ই এই মানটি আপডেট করুন (এটি ট্রিগারগুলির সাহায্যে বা সন্নিবেশকে সংশোধন করে মুছে ফেলা পদ্ধতিগুলি অর্জন করা যেতে পারে) ।
এটি অবশ্যই প্রতিটি সন্নিবেশ এবং মুছে ফেলার জন্য অতিরিক্ত বোঝা রাখবে তবে একটি সঠিক গণনা সরবরাহ করবে।

নির্ভুলতা : 100% নির্ভুল গণনা।
দক্ষতা : খুব ভাল, অন্য টেবিল থেকে কেবল একটি একক সারি পড়তে হবে।
এটি ডাটাবেসে অতিরিক্ত লোড রাখে।
e) অ্যাপ্লিকেশন স্তরটিতে গণনা সংরক্ষণ ( ক্যাশিং ) - এবং 1 ম পদ্ধতি (বা পূর্ববর্তী পদ্ধতির সংমিশ্রণ) ব্যবহার করে। উদাহরণ: প্রতি 10 মিনিটে সঠিক গণনা ক্যোয়ারী চালান। দুটি গণনার মধ্যবর্তী সময়ে, ক্যাশেড মানটি ব্যবহার করুন।

নির্ভুলতা : আনুমানিকতা তবে সাধারণ পরিস্থিতিতে খুব খারাপ না (যদি না কয়েক হাজার সারি যুক্ত বা মুছে ফেলা হয় তবে)।
দক্ষতা : খুব ভাল, মান সর্বদা উপলব্ধ।

— ypercubeᵀᴹ
সূত্র

1

জন্য INNODBযদি আপনি চান information_schema.INNODB_SYS_TABLESTATS.NUM_ROWSপরিবর্তে, সঠিক টেবিল সারি গণনা ডেটার জন্য information_schema.TABLES.TABLE_ROWS।

আমি এখানে আরও বিশদ পোস্ট করেছি: /programming/33383877/why-does-information-schema-tables-give-such-an-unstable-answer-for-number-of-ro/49184843#49184843

— রব ব্রাডশ
সূত্র

1

ভুল তথ্য ... "InnoDB জন্য আপনি সঠিক টেবিল সারিতে information_schema.INNODB_SYS_TABLESTATS.NUM_ROWS চান:" ম্যানুয়াল স্পষ্টভাবে বলে অনুমান করা উপর NUM_ROWScolum

— রেমন্ড Nijland