Movatterモバイル変換

Theoperations_per_fragment table provides information about the operations performed on individual fragments and fragment replicas, as well as about some of the results from these operations.

Theoperations_per_fragment table contains the following columns:

Notes

Thefq_name contains the fully qualified name of the schema object to which this fragment replica belongs. This currently has the following formats:

The$unique suffix shown for unique indexes is added bymysqld; for an index created by a different NDB API client application, this may differ, or not be present.

The syntax just shown for fully qualified object names is an internal interface which is subject to change in future releases.

Consider a tablet1 created and modified by the following SQL statements:

CREATE DATABASE mydb;USE mydb;CREATE TABLE t1 (  a INT NOT NULL,  b INT NOT NULL,  t TEXT NOT NULL,  PRIMARY KEY (b)) ENGINE=ndbcluster;CREATE UNIQUE INDEX ix1 ON t1(b) USING HASH;

Ift1 is assigned table ID 11, this yields thefq_name values shown here:

For indexes orBLOB tables, theparent_fq_name column contains thefq_name of the corresponding base table. For base tables, this column is alwaysNULL.

Thetype column shows the schema object type used for this fragment, which can take any one of the valuesSystem table,User table,Unique hash index, orOrdered index.BLOB tables are shown asUser table.

Thetable_id column value is unique at any given time, but can be reused if the corresponding object has been deleted. The same ID can be seen using thendb_show_tables utility.

Theblock_instance column shows which LDM instance this fragment replica belongs to. You can use this to obtain information about specific threads from thethreadblocks table. The first such instance is always numbered 0.

Since there are typically two fragment replicas, and assuming that this is so, eachfragment_num value should appear twice in the table, on two different data nodes from the same node group.

SinceNDB does not use single-key access for ordered indexes, the counts fortot_key_reads,tot_key_inserts,tot_key_updates,tot_key_writes, andtot_key_deletes are not incremented by ordered index operations.

Thetot_key_refs column shows the number of key operations refused by the LDM. Generally, such a refusal is due to duplicate keys (inserts),Key not found errors (updates, deletes, and reads), or the operation was rejected by an interpreted program used as a predicate on the row matching the key.

Theattrinfo andkeyinfo attributes counted by thetot_key_attrinfo_bytes andtot_key_keyinfo_bytes columns are attributes of anLQHKEYREQ signal (seeThe NDB Communication Protocol) used to initiate a key operation by the LDM. Anattrinfo typically contains tuple field values (inserts and updates) or projection specifications (for reads);keyinfo contains the primary or unique key needed to locate a given tuple in this schema object.

The value shown bytot_frag_scans includes both full scans (that examine every row) and scans of subsets. Unique indexes andBLOB tables are never scanned, so this value, like other scan-related counts, is 0 for fragment replicas of these.

tot_scan_rows_examined may display less than the total number of rows in a given fragment replica, since ordered index scans can limited by bounds. In addition, a client may choose to end a scan before all potentially matching rows have been examined; this occurs when using an SQL statement containing aLIMIT orEXISTS clause, for example.tot_scan_rows_returned is always less than or equal totot_scan_rows_examined.

tot_scan_bytes_returned includes, in the case of pushed joins, projections returned to theDBSPJ block in the NDB kernel.

tot_qd_frag_scans can be effected by the setting for theMaxParallelScansPerFragment data node configuration parameter, which limits the number of scans that may execute concurrently on a single fragment replica.