# Increasing Performance with VIEWS

**URL:** <https://forums.percona.com/t/increasing-performance-with-views/110>\
**Category:** Other MySQL® Questions\
**Created:** [October 30, 2006, 9:43am UTC](https://forums.percona.com/t/increasing-performance-with-views/110 "2006-10-30T09:43:01Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Speeple](https://avatars.discourse-cdn.com/v4/letter/s/73ab20/32.png) [@Speeple](https://forums.percona.com/u/Speeple)\
**Post date:** [October 30, 2006, 9:43am UTC](https://forums.percona.com/t/increasing-performance-with-views/110/1 "2006-10-30T09:43:01Z")

</div>

Hi,

I’m working on some blogging software which uses MySQL as a datas tore.

Each archive page, year, month, day can have a tag cloud generated to show the most popular tags for that day.

Currently I’m using a derived table. Then I stumbled across your article “Derived Tables and Views Performance” and tested a query with a VIEW and it was indeed theoretically faster because the number of rows required in the query that used the VIEW was SUBSTANTIALLY lower than that of the derived query.

What I was thinking of implementing was temporay VIEWs each time the tag cloud needs to be generated (every page view eek: ).

So it would go:

CREATE VIEW for IDs

PERFORM query USING VIEW

DROP VIEW

Remembering this would be performed every page view, for every visitor on every blog hosted (we’re talking a lot of VIEWS being created and DROPPED here) - how would it perform? Does this require a lot of IO operations?

Thank you!

---

<div class="post-metadata">

**Author:** ![Peter](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/peter/32/2_2.png) [@Peter](https://forums.percona.com/u/Peter)\
**Post date:** [October 30, 2006, 10:55am UTC](https://forums.percona.com/t/increasing-performance-with-views/110/2 "2006-10-30T10:55:13Z")

</div>

Why ask, better benchmark it )

Generally it hould not be that expensive however if --sync-frm is dependent it may need fsync which is relatively expensive.
