<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Table Scan &#8211; Database Research &amp; Development</title>
	<atom:link href="https://www.dbrnd.com/tag/table-scan/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.dbrnd.com</link>
	<description>BIGData &#124; NoSQL &#124; MSSQL &#124; MySQL &#124; PostgreSQL</description>
	<lastBuildDate>Thu, 16 Nov 2017 07:20:31 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.5</generator>
	<item>
		<title>Database Theory: Table Scan vs Index Scan vs Index Seek</title>
		<link>https://www.dbrnd.com/2016/04/database-theory-table-scan-vs-index-scan-vs-index-seek/</link>
					<comments>https://www.dbrnd.com/2016/04/database-theory-table-scan-vs-index-scan-vs-index-seek/#comments</comments>
		
		<dc:creator><![CDATA[Anvesh Patel]]></dc:creator>
		<pubDate>Mon, 18 Apr 2016 20:22:33 +0000</pubDate>
				<category><![CDATA[Database Theory]]></category>
		<category><![CDATA[Anvesh Patel]]></category>
		<category><![CDATA[database]]></category>
		<category><![CDATA[database concept]]></category>
		<category><![CDATA[database research and development]]></category>
		<category><![CDATA[database standards]]></category>
		<category><![CDATA[database topic]]></category>
		<category><![CDATA[dbrnd]]></category>
		<category><![CDATA[Index Scan]]></category>
		<category><![CDATA[Index Seek]]></category>
		<category><![CDATA[RDBMS]]></category>
		<category><![CDATA[Table Scan]]></category>
		<guid isPermaLink="false">https://www.dbrnd.com/?p=2375</guid>

					<description><![CDATA[Table Scan: It scans every row for finding a particular node or data. If the planner fails to use a proper index, it has to do full Table Scanning. If table has a less number of records, Table Scan is an excellent choice for query optimizer. For example, If Table has around 1000 records, Table [&#8230;]]]></description>
										<content:encoded><![CDATA[<p><a class="a2a_button_facebook" href="https://www.addtoany.com/add_to/facebook?linkurl=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&amp;linkname=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" title="Facebook" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_twitter" href="https://www.addtoany.com/add_to/twitter?linkurl=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&amp;linkname=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" title="Twitter" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_linkedin" href="https://www.addtoany.com/add_to/linkedin?linkurl=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&amp;linkname=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" title="LinkedIn" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_pinterest" href="https://www.addtoany.com/add_to/pinterest?linkurl=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&amp;linkname=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" title="Pinterest" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_reddit" href="https://www.addtoany.com/add_to/reddit?linkurl=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&amp;linkname=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" title="Reddit" rel="nofollow noopener" target="_blank"></a><a class="a2a_button_pocket" href="https://www.addtoany.com/add_to/pocket?linkurl=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&amp;linkname=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" title="Pocket" rel="nofollow noopener" target="_blank"></a><a class="a2a_dd addtoany_share_save addtoany_share" href="https://www.addtoany.com/share#url=https%3A%2F%2Fwww.dbrnd.com%2F2016%2F04%2Fdatabase-theory-table-scan-vs-index-scan-vs-index-seek%2F&#038;title=Database%20Theory%3A%20Table%20Scan%20vs%20Index%20Scan%20vs%20Index%20Seek" data-a2a-url="https://www.dbrnd.com/2016/04/database-theory-table-scan-vs-index-scan-vs-index-seek/" data-a2a-title="Database Theory: Table Scan vs Index Scan vs Index Seek"></a></p><p><strong>Table Scan:</strong></p>
<blockquote><p>It scans every row for finding a particular node or data. If the planner fails to use a proper index, it has to do full Table Scanning.<br />
If table has a less number of records, Table Scan is an excellent choice for query optimizer.</p></blockquote>
<blockquote><p>For example, If Table has around 1000 records, Table Scan is faster because unnecessary Index Scanning operation is not required.<br />
But, If the Table has a large number of records, Table Scan requires high CPU and other resources for scanning the whole table. </p></blockquote>
<p><strong>Index Scan: </strong></p>
<blockquote><p>It is scanning of each row, whenever you are retrieving more than 50% or 70% of the table data, internally planner performing full Index Scan. </p></blockquote>
<blockquote><p>Generally, Index pages and Data pages are stored separately.<br />
Index scanning is also dependent on the ordering of the Index data because If matched key found from the top pages, Index Scan is not required. </p></blockquote>
<blockquote><p>The Row Lookups also involved in Index Scanning because matched Index key has to fetch data from the data page, so Index Scanning is very costly for the big table. </p></blockquote>
<p><strong>Index Seek:</strong></p>
<blockquote><p>Index Seek is opposite the Table Scan and Index Scan.<br />
It touches the only qualified row index rather than scanning whole Index Pages, and after that, it fetches only qualified data page. </p></blockquote>
<blockquote><p>When we are fetching less number of records with the specific filter, the planner has to choose Index Seek to fetch and scan only qualified data.</p>
<p>Index Seek operation is much faster than Index Scan, and also it does not require more CPU and I/O resources. </p></blockquote>
]]></content:encoded>
					
					<wfw:commentRss>https://www.dbrnd.com/2016/04/database-theory-table-scan-vs-index-scan-vs-index-seek/feed/</wfw:commentRss>
			<slash:comments>3</slash:comments>
		
		
			</item>
	</channel>
</rss>
