H2S30: A primer on the WP-database:

<X.ref: WP.MIC-H2S4> Kinsta.com<a-r>: WordPress uses a database management | system called MySQL, which is open source software. Hu: The WP-db is distinct | from WP-files, where the database, generally, contains dynamic, and user-edited, including user–account, files, and requires a higher | rate of request and response, from the front | end, than the files, which contain, essentially, the templates, and instructions, for how these requests should be processed, and the output, displayed, on the front end<Turing> Therefore, logically, all database | software has to be high-throughput, in the requests that they can manage, per second, even more so than HTML/CSS, since each user’s browser, only sends that individual’s requests, whereas the database, must handle | requests, from all users, at the same time #

CM H4S1: MySQL’s history with Oracle:

Hu: MySQL has much more in depth docs than PHP, and is the only open sourced component # of BOWSER that is owned by a large corporation $203-bn, 10/27, which has the resources to maintain the docs at an adequate level. Therefore, it makes sense to invest deeply in this component of the stack, and rely upon it for scalability. Much of our programming will be done with INDEX and table design in MySQL, to reduce script load, and optimize load times. X.ref-<WP.MIC-H2S67>

H3S1: phpMyAdmin:

Hu: Dreamhost offers access to the WP-db, which is located at mysql.[your-domain], using a file | manager called phpMyAdmin: phpMyAdmin is a free software tool written in PHP, intended to handle the administration of MySQL over the Web. <phpMyAdmin>: phpMyAdmin supports a wide range of operations on MySQL and MariaDB. Frequently used operations (managing databases, tables, columns, relations, indexes, users, permissions, etc) can be performed via the user | interface, while you still have the ability to directly execute any SQL statement.

H4S1: While the phpMyAdmin | interface is useful for scoping out the WP-db, troubleshooting, and identifying the file path to Kinsta.com: wp_commentmeta, wp_comments, wp_links, wp_options, wp_postmeta, wp_posts, wp_terms, wp_termmeta, wp_term_relationships, wp_term_taxonomy, wp_usermeta, wp_users. Hu: Since many of Chess-WP‘s custom | plugins work with wp_posts, we will be accessing these tables, in the database, especially.

H4S2: WP-db data structure:

H3S2: WP.db-queries,library:

H4S1: INSERT INTO statement:

W3Schools: The INSERT INTO statement is used to add new records to a MySQL table: W3Schools<a-r>: Here are some syntax rules to follow: The SQL query must be quoted in PHP String values inside the SQL query must be quoted Numeric values must not be quoted The word NULL must not be quoted.

phpMyAdmin:

INSERT INTO `wp_posts` (`post_ID`, `post_author`, `post_content`, `post_title`) VALUES ('1', 'blind', 'Text text', 'Text text text text');

H5S1: Testing an insert | statement for page.instance–creation:

Hu: We will create # a separate PHP-file to handle the INSERT statement, and then consider, where to build this into our workflow: page.insert-inc.php:

<?php 
require 'database.php'; 
$sql = "INSERT INTO wp_posts (post_ID, post_author, post_title, text1, url1, text2, url2) VALUES ('2', 'blind', 'p.dash-2,entertain', 'ITZY.YT', 'https://www.youtube.com/results?search_query=itzy', 'Twice.YT', 'https://www.youtube.com/results?search_query=twice')";
	$conn->query($sql); 
?>

Hu: Testing outcome; this include, when loaded directly as http://personal-dash/page.insert-inc.php, successfully adds the following row to db:

H4S2: UPDATE statement:

W3Schools<a-r>: The UPDATE statement is used to update existing records in a table:

UPDATE table_name
SET column1=value, column2=value2,...
WHERE some_column=some_value 

Hu: On average #, a table update function contains 15+ lines, in a PHP document #, as separate statements, must pinpoint, in the database, including 1) the table_name, 2) the column, in the table, of reference, and 3) the row, or value, and this only identifies the location in which a transformation will occur. W3Schools:

<?php
$servername = "localhost";
$username = "username";
$password = "password";
$dbname = "myDB";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);
// Check connection
if ($conn->connect_error) {
  die("Connection failed: " . $conn->connect_error);
}

$sql = "UPDATE MyGuests SET lastname='Doe' WHERE id=2";

if ($conn->query($sql) === TRUE) {
  echo "Record updated successfully";
} else {
  echo "Error updating record: " . $conn->error;
}

$conn->close();
?>

Hu: For PHP MySQL, the equivalent # of the MySQL update statement is the line: $sql = “UPDATE MyGuests SET lastname=’Doe’ WHERE id=2”;

H5S1: H7S1: The WP-SELECT statement:<WP.MIC-H2S39,H3S8.H4S1-H5S6,H6S1.H7S1>

H4S3: SELECT statement:

W3Schools<a-r>: The SELECT statement is used to select data from one or more tables:

SELECT column_name(s) FROM table_name

or we can use the * character to select ALL columns from a table:

SELECT * FROM table_name

$sql = "SELECT id, firstname, lastname FROM MyGuests";
$result = $conn->query($sql);

W3Schools: First, we set up an SQL query that selects the id, firstname and lastname columns from the MyGuests table. The next line of code runs the query and puts the resulting | data into a variable called $result.

H5S1: H7S2: The WP-SELECT statement:<WP.MIC-H2S39,H3S8.H4S1-H5S6,H6S1.H7S2>

H4S4: The WHERE clause:

W3Schools: The WHERE | clause is used to filter records. The WHERE clause is used to extract only those records that fulfill a specified | condition.

SELECT column_name(s) FROM table_name WHERE column_name operator value 

H5S1: SELECT x WHERE:

$sql = "SELECT id, firstname, lastname FROM MyGuests WHERE lastname='Doe'";
$result = $conn->query($sql);

W3Schools: First, we set up the SQL query that selects the id, firstname and lastname columns from the MyGuests table where the lastname is “Doe“. The next line of code runs the query and puts the resulting data into a variable called $result.

H4S5: The DELETE statement:

W3Schools: The DELETE | statement is used to delete existing records in a table.

DELETE FROM table_name WHERE condition;

DELETE FROM Customers WHERE CustomerName='Alfreds Futterkiste';

Hu: The above code will delete an entire row, with data from each column, in that row, in the table “Customers“, which contains # the name ‘Alfreds Futterkiste’.

H5S1: Delete all records: It is possible to delete all rows in a table without deleting the table. This means that the table structure, attributes, and indexes will be intact:

DELETE FROM table_name;

H4S6: ORDER BY keyword:

W3<a-r>:

SELECT column_name(s) FROM table_name ORDER BY column_name(s) ASC|DESC 

H4S7: LIMIT-clause:

SELECT column_name(s)
FROM table_name
WHERE condition
LIMIT number;

W3: The LIMIT clause is used to specify the number of records to return. The LIMIT clause is useful on large tables with thousands of records. Returning a large number of records can impact performance.

H4S8: DEFAULT-constraint:

Hu: To avoid parsing | errors<WP.MIC-H2S64>, we can use the DEFAULT constraint, in conjunction with the CREATE statement, to establish a default value, for a particular column, that may be empty: W3: The default value will be added to all new records, if no other value is specified. Hu: Default can be used with other statements, such as ALTER and defaults can also be DROP’d.

H4S9: The CREATE INDEX statement:

dev-MySQL: Indexes are used to find rows with specific column values quickly. Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows. The larger the table, the more this costs. If the table has an index for the columns # in question, MySQL can quickly determine the position to seek to in the middle of the data file without having to look at all the data. This is much faster than reading every row sequentially. Hu: the INDEX is reflective of a phylogenetic dichotomous tree, in evolutionary biology. Britannica<a-r>: Biologists who postulate phylogenies derive their most-useful evidence from the fields of paleontology, comparative anatomy, comparative embryology, and molecular genetics. Studies of the molecular structure of genes and of the geographic distribution of flora and fauna are also useful. The fossil | record is often used to determine the phylogeny of groups containing hard body parts; it is also used to date divergence times of species in phylogenies that have been constructed on the basis of molecular evidence. dev-MySQL: Most MySQL indexes (PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are stored in B-trees. Exceptions: Indexes on spatial data types use R-trees; MEMORY tables also support hash indexes; InnoDB uses inverted | lists for FULLTEXT indexes.

H5S1: B-TREE:

dev-MySQL: A tree data structure that is popular for use in database | indexes. The structure is kept sorted at all times, enabling fast | lookup for exact | matches (equals operator) and ranges (for example, greater than, less than, and BETWEEN operators). This type of index is available for most storage engines, such as InnoDB and MyISAM. Because B-tree nodes can have many | children, a B-tree is not the same as a binary | tree, which is limited to 2 children per node.

H5S2: Karsten Müller: the heir to Thompson:

Hu: Two of the most prolific applications of db-prog to chess-theory, first by Ken Thompson<b-1943> and next by Karsten Müller<b-1970>, of a later | generation. // add quote from Müller.

H5S3: Applications of indexing:

dev-MySQL: MySQL uses indexes for these operations: To find the rows matching a WHERE clause quickly. To eliminate rows from consideration. If there is a choice between multiple indexes, MySQL normally uses the index that finds the smallest number of rows (the most selective index).

H5S4: Numerical indexing<Turing>:

Hu: ⭐ Indexing a number: number of digits will provide a variable reduction, and subsequently, indexing at every digit, from left to right, will reduce search scope by 1/10th, per digit. Indexing numbers that are pre-ordered eliminates the need for search, entirely. By default, if a numerical | index is available in one’s tb-setup, it’ll be best, to use it<Turing>

H5S5: Multi.column-indexes:

Dev-MySQL: //

H5S6: The str-E of CREATE INDEX:

Dev-MySQL: Normally, you create all indexes on a table at the time the table itself is created with CREATE TABLE. See Section 13.1.18, “CREATE TABLE Statement”. This guideline is especially important for InnoDB tables, where the primary key determines the physical layout of rows in the data file. CREATE INDEX enables you to add indexes to existing | tables. CREATE INDEX is mapped to an ALTER TABLE statement to create indexes.<Ch-19>

H5S7: Index choice:

Index Class	Index Type	Stores NULL VALUES	Permits Multiple NULL Values	IS NULL Scan Type	IS NOT NULL Scan Type
Primary key	BTREE	No	No	N/A	N/A
Unique	BTREE	Yes	Yes	Index	Index
Key	BTREE	Yes	Yes	Index	Index
FULLTEXT	N/A	Yes	Yes	Table	Table
SPATIAL	N/A	No	No	N/A	N/A

H6S1: Unique: dev-MySQL: A UNIQUE index creates a constraint such that all values in the index must be distinct. An error occurs if you try to add a new row with a key value that matches an existing row. If you specify a prefix value for a column in a UNIQUE index, the column values must be unique | within the prefix length<H5S8>

H6S2: Primary:

H6S3: Index:

H6S4: Spatial: The MyISAM, InnoDB, NDB, and ARCHIVE storage engines support spatial columns such as POINT and GEOMETRY.

H6S5: Full-text: dev-MySQL: FULLTEXT indexes are supported only for InnoDB and MyISAM tables and can include only CHAR, VARCHAR, and TEXT columns. Full-text | searching is performed using MATCH() AGAINST() syntax. MATCH() takes a comma-separated | list that names the columns to be searched. AGAINST takes a string to search for, and an optional | modifier that indicates what type of search to perform. The search string must be a string value that is constant during query | evaluation. This rules out, for example, a table column because that can differ for each row. H7S1: Natural language search H7S2: Boolean search H7S3: A query expansion search<Google><50%> is a modification of a natural language search. The search string is used to perform a natural language search. Then words from the most relevant rows returned by the search are added to the search string and the search is done again. The query returns the rows from the second search. 

H5S8: Prefix value: dev-MySQL: For string columns, indexes can be created that use only the leading part of column values, using col_name(length) syntax to specify an index prefix length: Prefixes can be specified for CHAR, VARCHAR, BINARY, and VARBINARY key parts.

Post-?: Hu: Why would you not want to index a column, and what are the downsides? Self-answer: restraints would be one, for UNIQUE index application # For example, you would not want to UNIQUE index a column, that contains author name, in a table in which multiple posts might be by the same author. However, that doesn’t prevent you from using a KEY, INDEX, or non-unique index, to that column.

H3S3: Security and scalability vulnerability # case study: wp-custom-template:

Hu, x-ref<LA.WooCommerce-meetup>: Site Editor<WP.MIC-H2S2> is a new | feature released in WP.5-9, released on Jan.25-2022<a-r>: and is clearly still in a beta | stage, due to a key # security | flaw: when the theme folder is exported from WP-backup, and accessed via FTP.file-access, only the default | themes files are displayed:

Hu: While the FTP.access-backup exports only the files from the templates folder, in file-access, the domain–specific backup, through the wp-admin flow specified in [D, L] grabs files also, from the wp-database, in a separate location #, where certain user-generated | template files, are also stored.

H3S4: MySQL lit-rev:

H4S1: Collation setting:

dev.MySQL-10,14<a-r>: A collation is a set of rules that defines how to compare and sort character strings. Each collation in MySQL belongs to a single character set. Every character set has at least one collation, and most have two or more collations. A collation orders characters based on weights. H5S1: <Poulson, p-m>: MySQL allows you to specify | character sets and collations at four | levels: the server, database, table, and column. For WordPress sites, the recommended charset is utf8mb4 and the recommended collation is utf8mb4_unicode_ci .

H4S2: Establishing db-conn:

W3Schools: PHP 5 and later can work with a MySQL database using: MySQLi extension (the “i” stands for improved) or PDO (PHP Data Objects).

<?php
$servername = "localhost";
$username = "root";
$password = "";
$dbname = "dash-test";

// Create connection
$conn = new mysqli($servername, $username, $password, $dbname);

// Check connection
if ($conn->connect_error) {
	die("Connection failed: " . $conn->connect_error);
	} else {
	echo "Connection successful!";
	}

?>

Hu: The first 4 lines of the above code # establish | variables, in PHP, that are required, in the MySQL conn-req. The connection is established by the declaration of the db-object, as the variable, assigned to the variable $conn. The last line, is a simple conditional # that returns an error if $conn has the property of # connect_error, and returns “Connection successful!”, if everything worked #

H4S3: Re-using the db-conn:

Hu: The ability to make a db-conn, and have it proven working, needs to be recycled | forward into other functions, in which the db-conn is useful. According to <Code with Dary a-r>, the db-conn should be stored in a separate | file, and WP does this as well #, with wp-db.php, and the single | line:

require_once 'includes/database.php';

for example, can be used, to pull the $conn variable, or $wpdb, in the case of WordPress, into any file, in which $conn is to be used. Logically, this should also be able to apply # in the same file, but it may be fundamentally correct, if one is to have numerous files, to abstract the db-conn into one location.

H4S4: Closing the conn:

$conn->close();

Code with Dary does not include this close statement in his database.php file, so we will exclude it as well, for now.

H4S5: Reading the db to load front end:

Hu: I am still idealistically # attempting to run HTML-pages as by user-serving | direct, but my pages need to be dynamic, by drawing the most recent user-updated | links from the db, in the content | area. For example, from my personal–dash implementation<WP.MIC-H2S10>:

Hu The second question is whether I should read | data selectively #<Turing, fbno> within one column in the db, or whether I would be behooved to split each of the 18 data-bytes # into their own column. Intuitively, the second option seems more scalable, because 1) on each page, I have a hard | limit, that is neurological, of 18 data-bytes, so there are no scalability concerns and 2) I have already committed to running this data on my own table, separately from wp_posts, when this is shipped to WP.

H4S6: $wpdb library dump:

Hu: Just trying to understand how this works, so my criteria for this section is simple: I CTRL+F’d $wpdb in the wpuf-functions.php file of Front End Plugin<a-r>, and simply pasted every line:

global $wpdb;
$users = $wpdb->get_results( "SELECT ID, user_login from $wpdb->users" );
$attachment_id = $wpdb->get_var( $wpdb->prepare( "SELECT wposts.ID FROM $wpdb->posts wposts, $wpdb->postmeta wpostmeta WHERE wposts.ID = wpostmeta.post_id AND wpostmeta.meta_key = '_wp_attached_file' AND wpostmeta.meta_value = %s AND wposts.post_type = 'attachment'", $attachment_url ) );

        $results = $wpdb->get_col( $wpdb->prepare( "SELECT t.name FROM $wpdb->term_taxonomy AS tt INNER JOIN $wpdb->terms AS t ON tt.term_id = t.term_id WHERE tt.taxonomy = %s AND t.term_id IN ($term_ids) AND t.name LIKE (%s)", $taxonomy, '%' . $wpdb->esc_like( $s ) . '%' ) );
    } else {
        $results = $wpdb->get_col( $wpdb->prepare( "SELECT t.name FROM $wpdb->term_taxonomy AS tt INNER JOIN $wpdb->terms AS t ON tt.term_id = t.term_id WHERE tt.taxonomy = %s AND t.name LIKE (%s)", $taxonomy, '%' . $wpdb->esc_like( $s ) . '%' ) );

        return $wpdb->get_var( "SELECT COUNT(*) FROM {$wpdb->prefix}wpuf_transaction" );

    $result = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}wpuf_transaction ORDER BY `{$args['orderby']}` {$args['order']} LIMIT {$args['offset']}, {$args['number']}", OBJECT );

    $transaction_table = $wpdb->prefix . 'wpuf_transaction';

        return ( int ) $wpdb->get_var(
            "SELECT SUM(AllCount)
            FROM ((SELECT COUNT(*) AS AllCount FROM {$transaction_table})
            UNION ALL
                (SELECT COUNT(*) AS AllCount FROM {$wpdb->posts}
                    WHERE post_type = 'wpuf_order'
                    AND post_status IN('pending', 'publish'))) AS post_table"
        );

    $transactions = $wpdb->get_results(
        $wpdb->prepare(
            "(SELECT id, user_id, status, tax, cost, post_id, pack_id, payer_first_name, payer_last_name, payer_email, payment_type, transaction_id, created FROM {$transaction_table})
            UNION ALL
            (SELECT ID AS id, post_author AS user_id, null AS status, null AS tax, null AS cost, ID as post_id, null AS pack_id, null AS payer_first_name, null AS payer_last_name, null AS payer_email, null AS payment_type, 0 AS transaction_id, post_date AS created FROM {$wpdb->posts}
            WHERE post_type = %s)
            ORDER BY {$orderby} {$sorting_order}
            LIMIT %d, %d",
            'wpuf_order', $offset, $number
        )
    );

    $wpdb->delete(
        $wpdb->posts,
        [
            'post_parent' => $form_id,
            'post_type'   => 'wpuf_input',
        ]
    );

Hu: Some observations 1) $wpdb | requests are frequently used with a result | keyword<WP.H2S35-H3S3,H4S5>, or with a $result variable definition, a sort of stylistic | norm<Turing>. Many are complex-threaded within conditional statements, and it looks like north of 50% are read-requests, rather than write-requests #

H3S5: Database segregation<Turing>:

Hu: Data is inherent, and, arguably, has an independent | form from how it’s stored, and the structure of that storage. When the structure of data is meaningfully | different, we strive to store | these | data in different | tables, since each table can have its own column | structure.

H4S1: Mitigating | security | risk<Turing>:

The tendency # of WP to mix all types of content into wp_posts poses an immediate to intermediate security and scalability | risk, since some of these contents, have meaningfully | different | properties, such that # the weight of column usage may differ from one type to another, and eventually, a segregation will have to be established, but now, at the cost of significant refactoring, that limits scalability, by establishing a cost | barrier #

H4S2: ORDER BY limitation<Turing>:

Hu: In order to implement a dynamic | count-return that, for example, allows you to dynamically add a new | post with post_ID = the last, or highest, post_ID + 1, it is necessary # to SELECT all the entries in the post_ID column of the table and run an ORDER BY operation. This is, by definition, unscalable, with a hard | ceiling, and is a thematic | problem of large.data–operations.

H3S6: MySQLi functions library: #

H4S1: fetch_assoc()

<php.net>: Fetches one row of data from the result set and returns it as an associative | array. Each | subsequent call to this function will return the next row within the result set, or null if there are no more rows. Hu: Note that fetch_assoc() puts into an array, not all the rows, as, frequently, a query to a row # will contain data from multiple columns, but rather, the data, from each column. <php.net>: Returns an associative array representing the fetched row, where each key in the array represents the name of one of the result set’s columns, null if there are no more rows in the result set, or false on failure. Hu: A return statement is not necessary, in using this function, as it is automatic.

H5S1: While loop x fetch_assoc()<Turing-shared>

while($row = mysqli_fetch_assoc($result)) {
R: https://www.w3schools.com/php/php_mysql_select_orderby.asp

Hu: This line of code # will loop through # fetching of all rows from a tb, until some pre-specified condition is met # A subsequent computation can be performed on this output, which is assigned, stepwise, to the $row variable.

H4S2: fetch_row()

Fetches one row of data from the result set and returns it as an enumerated array, where each column is stored in an array offset starting from 0 (zero). Each subsequent call to this function will return the next row within the result set, or null if there are no more rows.

H3S7: InnoDB:

dev-MySQL: InnoDB is a general-purpose storage engine that balances high reliability and high performance. In MySQL 5.7, InnoDB is the default MySQL storage | engine. Unless you have configured a different default storage engine, issuing a CREATE TABLE statement without an ENGINE clause creates an InnoDB table.

Feature	Support
B-tree indexes	Yes
Backup/point-in-time recovery (Implemented in the server, rather than in the storage engine.)	Yes
Cluster database support	No
Clustered indexes	Yes
Compressed data	Yes
Data caches	Yes
Encrypted data	Yes (Implemented in the server via encryption functions; In MySQL 5.7 and later, data-at-rest encryption is supported.)
Foreign key support	Yes
Full-text search indexes	Yes (Support for FULLTEXT indexes is available in MySQL 5.6 and later.)
Geospatial data type support	Yes
Geospatial indexing support	Yes (Support for geospatial indexing is available in MySQL 5.7 and later.)
Hash indexes	No (InnoDB utilizes hash indexes internally for its Adaptive Hash Index feature.)
Index caches	Yes
Locking granularity	Row
MVCC	Yes
Replication support (Implemented in the server, rather than in the storage engine.)	Yes
Storage limits	64TB
T-tree indexes	No
Transactions	Yes
Update statistics for data dictionary	Yes

Definitions:

MySQL-dev: selectivity (n.) = A property of data distribution, the number of distinct values in a column (its cardinality) divided by the number of records in the table. High selectivity means that the column values are relatively unique, and can retrieved efficiently through an index. If you (or the query optimizer) can predict that a test in a WHERE clause only matches a small number (or proportion) of rows in a table, the overall query tends to be efficient if it evaluates that test first, using an index.

MySQL-dev: cardinality (n.) = The number of different values in a table column. When queries refer to columns that have an associated index, the cardinality of each column influences which access method is most efficient. For example, for a column with a unique constraint, the number of different values is equal to the number of rows in the table. If a table has a million rows but only 10 different values for a particular column, each value occurs (on average) 100,000 times. A query such as SELECT c1 FROM t1 WHERE c1 = 50; thus might return 1 row or a huge number of rows, and the database server might process the query differently depending on the cardinality of c1. If the values in a column have a very uneven distribution, the cardinality might not be a good way to determine the best query plan. For example, SELECT c1 FROM t1 WHERE c1 = x; might return 1 row when x=50 and a million rows when x=30. In such a case, you might need to use index hints to pass along advice about which lookup method is more efficient for a particular query. Cardinality can also apply to the number of distinct values present in multiple columns, as in a composite index.

Primary key (n.) = A set of columns—and by implication, the index based on this set of columns—that can uniquely identify every row in a table. As such, it must be a unique index that does not contain any NULL | values.

References:

https://kinsta.com/knowledgebase/wordpress-database/

https://www.phpmyadmin.net/

https://codex.wordpress.org/Database_Description#Table_Overview

https://docs.phpmyadmin.net/en/latest/

https://www.w3schools.com/php/php_mysql_insert.asp

https://www.w3schools.com/php/php_mysql_update.asp

Site Editor

Version 5.9

https://wordpress.com/support/full-site-editing/

A full list of SQL statements, dev-MySQL: https://dev.mysql.com/doc/refman/5.7/en/sql-statements.html

https://dev.mysql.com/doc/refman/8.0/en/adding-collation.html

Poulson, 2020: https://deliciousbrains.com/tour-wordpress-database/

https://www.php.net/manual/en/class.mysqli.php

https://www.w3schools.com/php/php_mysql_connect.asp

wpdb

wpdb::query()

WP User Frontend – Registration, User Profile, Membership, Content Restriction, User Directory, and Frontend Post Submission Plugin

https://www.w3schools.com/php/php_mysql_select.asp

https://www.w3schools.com/mysql/trymysql.asp?filename=trysql_select_orderby

https://www.w3schools.com/php/php_mysql_select_orderby.asp

https://www.php.net/manual/en/mysqli-result.fetch-assoc.php

https://www.w3schools.com/mysql/mysql_limit.asp

https://www.w3schools.com/mysql/mysql_default.asp

H4S1: Indexes:

• Index name can be self-selected #
• Did not specify # choice, packed, column, cardinality, collation, or null, everything but choice was auto-assigned visibly; choice, “Unique” displays no in the resulting table, but not other information provided.
• Created indexes for 2 columns: item, and casher. Both are numeric columns, in the original tb. Both are the columns, in which he runs a WHERE clause, in a SELECT search.

https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html

https://www.britannica.com/science/phylogeny/Taxonomic-systems

https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_b_tree

https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_selectivity

https://dev.mysql.com/doc/refman/8.0/en/glossary.html#glos_cardinality

https://dev.mysql.com/doc/refman/8.0/en/multiple-column-indexes.html

https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html

https://en.m.wikipedia.org/wiki/MySQL

https://en.m.wikipedia.org/wiki/C%2B%2B

https://en.wikipedia.org/wiki/History_of_the_internal_combustion_engine

https://dev.mysql.com/doc/refman/8.0/en/multiple-column-indexes.html

https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_primary_key

https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction.html

https://dev.mysql.com/doc/refman/5.7/en/fulltext-search.html

https://stackoverflow.com/questions/707874/differences-between-index-primary-unique-fulltext-in-mysql

• 700+ upvotes on the correct.

Issues:

Hu: For WP, should I use MySQLi or PDO?

Hu: Does the db, or the PHP, handle ORDER BY, which is the bulk of computation, in a db-sort?