the startups.com platform about startups.comCheck out the new Startups.com - A Comprehensive Startup University
Education
Planning
Mentors
Funding
Customers
Assistants
Clarity
Categories
Business
Sales & Marketing
Funding
Product & Design
Technology
Skills & Management
Industries
Other
Business
Career Advice
Branding
Financial Consulting
Customer Engagement
Strategy
Sectors
Getting Started
Human Resources
Business Development
Legal
Other
Sales & Marketing
Social Media Marketing
Search Engine Optimization
Public Relations
Branding
Publishing
Inbound Marketing
Email Marketing
Copywriting
Growth Strategy
Search Engine Marketing
Sales & Lead Generation
Advertising
Other
Funding
Crowdfunding
Kickstarter
Venture Capital
Finance
Bootstrapping
Nonprofit
Other
Product & Design
Identity
User Experience
Lean Startup
Product Management
Metrics & Analytics
Other
Technology
WordPress
Software Development
Mobile
Ruby
CRM
Innovation
Cloud
Other
Skills & Management
Productivity
Entrepreneurship
Public Speaking
Leadership
Coaching
Other
Industries
SaaS
E-commerce
Education
Real Estate
Restaurant & Retail
Marketplaces
Nonprofit
Other
Dashboard
Browse Search
Answers
Calls
Inbox
Sign Up Log In

Loading...

Share Answer

Menu
MySQL: What are the best ways to maximize database performance without simply adding tons of DRAM?
AM
AM
Andrew McGrath, Founder at Checkout 51 answered:

Can you describe the data in the table? I can think of a few solutions, most if which are based on the data you are storing.

For example, chances are when you have large tables you are probably not doing any summarization of your data. If possible pre-compute the result and spit out the answer from a shorter table or cache (a cache which is generate at the time of the summary being generated, only useful if you often request this data shortly after it being created - doesn't sound like you needed to do this though)

Another alternative would to be consider archiving of data. Is all the data required all the time? If not then consider a means of removing data you don't need (after x period of time) or switching to a new shard / table periodically.

The other, more obvious, I would mention are to reconsider your existing indexes or partitioning your tables, if you have not done this already.

You can start manually sharding tables across servers based on a hash of some kind but your Db is still relatively small (assuming you can summarize some of your data) and should not need this yet.

Talk to Andrew Upvote • Share
•••
Share Report

Answer URL

Share Question

  • Share on Twitter
  • Share on LinkedIn
  • Share on Facebook
  • Share on Google+
  • Share by email
About
  • How it Works
  • Success Stories
Experts
  • Become an Expert
  • Find an Expert
Answers
  • Ask a Question
  • Recent Answers
Support
  • Help
  • Terms of Service
Follow

the startups.com platform

Startups Education
Startup Planning
Access Mentors
Secure Funding
Reach Customers
Virtual Assistants

Copyright © 2025 Startups.com. All rights reserved.