Reserved de-dupe rules
Demerit's and Mick's answers are incorrect for the (built-in) reserved rules - though it's definitely confusing!

If a RuleGroup has a value in the name field, and that name corresponds to a filename in CRM/Dedupe/BAO/QueryBuilder, then the customized SQL in those files will be used. The existing entries in civicrm_rule for those RuleGroups are holdovers from before that system existed, and editing them has no effect.

"Standard" dedupe rules with multiple criteria are very inefficient compared to handwritten SQL, which is why this is a valuable technique.  You can create your own handwritten queries with hook_civicrm_dedupe, and the Veda dedupe extension has a number of excellent examples.  Note that this extension doesn't work on modern Civi because of some of its other functions, but the dedupe rules can be ripped out into something else.

Finally - I learned just yesterday that the built-in handwritten dedupe rules seem to execute different SQL when comparing in Unsupervised/Supervised mode (a single contact) vs. General mode (find all dupes).  While I haven't proved it, I suspect that if you're in the rare scenario of needing to optimize your unsupervised/supervised dedupes, creating a new class to extend CRM_Dedupe_BAO_QueryBuilder is the way to go.  I just posted org.agbu.optimizeddedupe to provide an example of this.

UPDATE: More clarification.

To understand how the queries work, it's best to look at an example, eg IndividualUnsupervised.php.

The internal function is used if you go to Contacts » Find and Merge Duplicate Contacts and click Use Rule.  The SQL query is:



            SELECT contact1.id as id1, contact2.id as id2, {$rg-&gt;threshold} as weight
            FROM civicrm_contact as contact1
              JOIN civicrm_email as email1 ON email1.contact_id=contact1.id
              JOIN civicrm_contact as contact2 ON
                contact1.first_name = contact2.first_name AND
                contact1.last_name = contact2.last_name
              JOIN civicrm_email as email2 ON
                email2.contact_id=contact2.id AND
                email1.email=email2.email
            WHERE contact1.contact_type = 'Individual'"


First, note that the weight is set to $rg-&gt;threshold - that is, the threshold in civicrm_rule_group.  In other words, if this SQL matches, these records automatically meet the threshold for that rule.  Hopefully that answers your main question!  If you remove that field, you can run this SQL as-is in a SQL client and get a complete list of the duplicates it would return.

To further clarify - unlike "regular" rules which are the result of several queries, each with their own weight - this runs a SINGLE query, and sets the weight equal to the rule's threshold.  So it's a straight yes/no answer whether a record is a duplicate, based on whether the SQL finds them.

That's not to say that you can't simulate length/weight, but it's tricky.  My org.agbu.optimizeddedupe rule has a SQL statement you can look at which gives the same results as this rule:



However, it took about 5 seconds to compare even a single submitted contact against the existing 165,000 contacts in this databse with the existing rule.  Now it's almost instantaneous.